With this PR I have taken all SQLAlchemy-specific code out of aospy_synthetic. This is the beginning of work to address #5.
All interactions with the database with aospy_synthetic are done through an AbstractBackend object, whose methods are defined in aospy_synthetic/abstract_db.py.
SQLAlchemy-specific code can be found in aospy_synthetic/test/test_objs/SQLBackend/.
Currently all that is implemented is adding objects to the database. This requires first checking to see if the object already exists in the database such that no duplicated objects are added. It will require further testing, but I think this is working reasonably well.
The API still needs work. Some things that should be addressed are:
How should the user specify the backend used? Ideally they shouldn't need to provide an argument to every object they create (as is the case now). In general I think this should only need to be done at the project level (and then have all child objects inherit recursively).
Giving the user the option of specifying via a keyword argument whether they want to track an object in the DB is partially set up via this pull-request, but I don't think is working completely. This again should be addressed with some sort of inheritance; any object that is a child (or lower) of an object that is specified not to be tracked, should also not be included in the DB.
How will we handle querying in an abstract manner? A kitchen-sink type method is probably not wise (what I currently have in abstract_db is more of a placeholder). What are the most important queries that a user could make?
With this PR I have taken all SQLAlchemy-specific code out of
aospy_synthetic. This is the beginning of work to address #5.aospy_syntheticare done through anAbstractBackendobject, whose methods are defined inaospy_synthetic/abstract_db.py.aospy_synthetic/test/test_objs/SQLBackend/.The API still needs work. Some things that should be addressed are:
abstract_dbis more of a placeholder). What are the most important queries that a user could make?