Use the flask-sqlalchemy metadata instead of creating a new one

[gouthambs]

I found a small issue with the way the MetaData is constructed in the sql.py. Would like to fix this if you are still taking pull requests!

[ashcrow]

@gouthambs Absolutely!

[gouthambs]

@ashcrow Here is some background for this issue. While working on the flask-blogging extension, I have a storage and the main engine similar to the flask-track-usage. I found that the storage tables were not recognized in the database migrations while using Alembic automigrate feature. It looks like the reason for that is the MetaData object should all be unified. The Flask-SQLAlchemy SQLAlchemy object has a metadata internally, and we can directly use that instead.

[ashcrow]

@gouthambs Ah, I see. Are you looking at allowing metadata to be passed into the set_up() so it can be reused if given (similar to the db=None input)?

[gouthambs]

Actually the db object has the metadata property. So we wont need to add any more variables.

[ashcrow]

@gouthambs :+1:

[ashcrow]

@gouthambs does this end up being:

-            meta = sql.MetaData()
+            if db:
+                meta = db.metadata
+            else:
+                meta = sql.MetaData()

[gouthambs]

@ashcrow Thats correct.

Another thing is I feel the tables should not be created by this storage class. Explicit invocation of db.create_all() should take care of that. Thats a small change in usage.

This is consistent with how Flask-SQLAlchemy models just create the table instances in the meta, but the explicit invocation of db.create_all() creates the tables.

[ashcrow]

@gouthambs I'll commit the above patch. Let's discuss explicit db.create_all() rather than creating the tables automatically if they do not exists in a different issue to keep the work separate.

[gouthambs]

@ashcrow Sure! Sounds good!

[ashcrow]

Work done in https://github.com/ashcrow/flask-track-usage/commit/23e0f8ef4e6647a0b873882ee184a7b7fa4f20fb. Closing this issue.