On 08/18/2013 03:53 AM, Joshua Harlow wrote:
I always just liked SQL as the database abstraction layer ;)
On a more serious note I think novas new object model might be a way to go but
in all honesty there won't be a one size fits all solution. I just don't think
sqlalchemy is that solution personally (maybe if we just use sqlalchemy core it
will be better and eject just the orm layer).
What is specifically wrong with SQLAlchemy's ORM layer? What would you
replace it with? Why would use SQLAlchemy's "core" be better?
I've seen little evidence that SQLAlchemy's ORM layer is the cause for
database performance problems. Rather, I've found that the database
schemas in use -- and in some cases, the *way* that the SQLAlchemy ORM
is called (for example, doing correlated subqueries instead of straight
joins) -- are primary causes for database performance issues.
Note, I'm not speaking about database scalability issues but rather pure
query performance...
Best,
-jay
On Aug 16, 2013, at 12:07 PM, "Jay Pipes" <jaypi...@gmail.com> wrote:
On 08/16/2013 02:41 PM, Mark Washenberger wrote:
I think the issue here for glance is whether or not oslo common code
makes it easier or harder to make other planned improvements. In
particular, using openstack.common.db.api will make it harder to
refactor away from a giant procedural interface for the database driver.
And towards what? A giant object-oriented interface for the database driver?
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
