3 ms·

Isn't that about just switching the db driver in the ORM? Sorry for being sarcastic, but was that not exactly the point of countless database abstraction layer

Isn't that about just switching the db driver in the ORM? Sorry for being sarcastic, but was that not exactly the point of countless database abstraction layer projects?

deusex_ 7y ago
Uh, no? The idea is to have a full featured object mapping layer that can work with multiple database backends. Doing mapping of db result sets to object is non trivial, no need to do develop it multiple times for each RDMBS when 90% of the code would overlap. I'd work on the sarcastic attitude though
e12e 7y ago
Yes and no. The point of an actual ORM (object relational mapper) is to be able to the equivalent of lisp/smalltalk (runtime) image level perstiance: make objects permanent between restarts and changes transactional. To really get there, you actually need a object db, like zoodb[z] for python (which incidentally can use pg as a storage back-end). If you're using a db abstraction layer, and a typical active record like surrogate keys - then for simple use cases you can indeed switch back-ends; many rails projects run tests on sqlite and production on postgresql. That's not a great idea, but it works for simple projects (first gotcha; most rdbms don't have a global namspace for indexes; sqlite does). But there's no standard AFAIK for full text indexes, geodata, json/bson, materialized views... So it depends a lot on how much of the db you're actually using. [z] http://www.zodb.org/en/latest/tutorial.html http://www.zodb.org/en/latest/tutorial.html Note that an object db does not free you from thinking about data structure migrations: http://www.zodb.org/en/latest/guide/writing-persistent-objects.html http://www.zodb.org/en/latest/guide/writing-persistent-objec... https://pypi.org/project/zope.generations/ https://pypi.org/project/zope.generations/
Shorel 7y ago
And they only work that way if you switch the DB driver frequently during the development of your product. The abstraction is useful. The abstraction is leaky.
RantyDave 7y ago
Yes and no. You still need to ETL the data from one db to the other and (quite probably) the SQL dialects will be different so doing a dump'n'load isn't going to work.
HelloNurse 7y ago
For a real life metaphor, changing address in order to receive mail is easy; moving to a new house is the complicated and expensive part of the change.

Isn't that about just switching the db driver in the ORM? Sorry for being sarcastic, but was that not exactly the point of countless database abstraction layer projects?

deusex_ 7y ago

Uh, no? The idea is to have a full featured object mapping layer that can work with multiple database backends. Doing mapping of db result sets to object is non trivial, no need to do develop it multiple times for each RDMBS when 90% of the code would overlap. I'd work on the sarcastic attitude though

e12e 7y ago

Yes and no. The point of an actual ORM (object relational mapper) is to be able to the equivalent of lisp/smalltalk (runtime) image level perstiance: make objects permanent between restarts and changes transactional. To really get there, you actually need a object db, like zoodb[z] for python (which incidentally can use pg as a storage back-end). If you're using a db abstraction layer, and a typical active record like surrogate keys - then for simple use cases you can indeed switch back-ends; many rails projects run tests on sqlite and production on postgresql. That's not a great idea, but it works for simple projects (first gotcha; most rdbms don't have a global namspace for indexes; sqlite does). But there's no standard AFAIK for full text indexes, geodata, json/bson, materialized views... So it depends a lot on how much of the db you're actually using. [z] http://www.zodb.org/en/latest/tutorial.html http://www.zodb.org/en/latest/tutorial.html Note that an object db does not free you from thinking about data structure migrations: http://www.zodb.org/en/latest/guide/writing-persistent-objects.html http://www.zodb.org/en/latest/guide/writing-persistent-objec... https://pypi.org/project/zope.generations/ https://pypi.org/project/zope.generations/

Shorel 7y ago

And they only work that way if you switch the DB driver frequently during the development of your product. The abstraction is useful. The abstraction is leaky.

RantyDave 7y ago

Yes and no. You still need to ETL the data from one db to the other and (quite probably) the SQL dialects will be different so doing a dump'n'load isn't going to work.

HelloNurse 7y ago

For a real life metaphor, changing address in order to receive mail is easy; moving to a new house is the complicated and expensive part of the change.