[sqlalchemy] Re: SQLAlchemy 0.4.1 released
I very much appreciate the API hardening. It immediately broke tests of mine, exhibiting year-old abuse of save(). thank you ! Ruben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.1 released
I hear Super Mario Galaxy is one hell of a game!
On Nov 18, 7:26 pm, Michael Bayer [EMAIL PROTECTED] wrote:
Hello alchemers -
This is an awesome release. I'm excited about this one. With our new
shiny clean 0.4 codebase, internals are starting to look a lot more
intelligent, and new things are becoming possible. Call counts are
going down like a rock. Intents and behaviors are clarifying and
sharpeningplus Super Mario Galaxy arrives tomorrow so its time for
a break.
Some highlights of this release:
- you might notice that some eager load operations are suddenly a lot
faster, particularly on MySQL. This is because we've improved the
queries that are issued when you use eager loading with LIMIT and/or
OFFSET; whereas we previously would wrap the LIMITed query in a
subquery, join back to the mapped table, and then add the eager
criterion outer joined against the mapped table, a trick we've been
doing since 0.1.0, we now outer join the eager criterion directly
against the subquery, and the main mapper pulls rows straight from the
subquery columns. Improved SQL expression functionality has allowed
this to be possible. What it means is, an eager load with LIMIT/
OFFSET uses one less JOIN in all cases. This is an example of SA's
very rich expression constructs paying off - since a query that is
much more efficient on the database side trumps the hundred or so
method calls spent compiling the query anyday.
- session.refresh() and session.expire() can now operate on individual
instance attributes. Just say session.expire(myobject, ['items',
'description', 'name']), and all three of those attributes, whether
they're just columns or relations to other objects, will go blank
until you next access them on the instance, at which point they are
refreshed from the DB. Column attributes will be grouped together in
a single select() statement and related tables will be lazy loaded
individually right now. Also, the internal mechanisms used by
deferred() columns, refresh/expire operations, and polymorphically
deferred columns have all been merged into one system, which means
less internal complexity and more consistent behavior.
- the API of the session has been hardened. This means its going to
check more closely that operations make sense (and it also no longer
raises some errors that did not make sense in certain circumstances).
The biggest gotcha we've observed so far from people using trunk is
that session.save() is used *only* for entities that have not been
saved to the database yet. If you put an already-stored instance in
save(), you'll get an error. This has always been the contract, it
just hasn't complained previously. If you want to put things in the
session without caring if they've already been saved or not, use
session.save_or_update(myinstance). We've also fixed things regarding
entities that have been de-pickled and placed back into the session -
some annoying errors that used to occur have been fixed.
- still in the session category, the merge() method gets a
dont_load=True argument. Everyone using caches like memcached can
now place copies of their cached objects back in the session using
myinstance = merge(mycachedinstance, dont_load=True), and the
instance will be fully copied as though it were loaded from the
database, *without* a load operation proceeding; it will trust that
you want that instance state in the session.
- query.options() are way more intelligent. Suppose you have a large
bidirectional chain of relations. If you say something like
query.options(eagerload('orders.items.keywords.items.orders')), it
will accurately target the 'orders' relation at the end of that chain
and nothing else. On a similar topic, self-referential eagerloads can
be set up on the fly, such as
query.options(eagerload_all('children.children.children')) without
needing to set the join_depth flag on relation().
- method call overhead continues to be cut down. Many expensive calls
in statement compilation, clauseelement construction, and statement
execution have been whacked away completely and replaced with simpler
and more direct behaviors, and results are more accurate and correct.
This continues along from all that we've done in 0.4 and at this point
most call counts should be half of what they were in 0.3. I invite
everyone to take a tour around expression.py, compiler.py, and
critique; we've had a huge amount of housecleaning in these modules
(and others), and further suggestions/ideas/flames are entirely
welcome (though not too early in the morning) on sqlalchemy-devel.
- in the fringe category, you can now define methods like __hash__(),
__nonzero__(), and __eq__() on your mapped instances and the ORM won't
get confused; we've rearranged things so that those methods are not
accessed by the ORM.
- a new, experimental MaxDB dialect, lots of typing fixes for MySQL
and Oracle, and lots more.
As
[sqlalchemy] Re: SQLAlchemy 0.4.1 released
Thanks Mike. Cool stuff!
On Nov 19, 1:26 am, Michael Bayer [EMAIL PROTECTED] wrote:
Hello alchemers -
This is an awesome release. I'm excited about this one. With our new
shiny clean 0.4 codebase, internals are starting to look a lot more
intelligent, and new things are becoming possible. Call counts are
going down like a rock. Intents and behaviors are clarifying and
sharpeningplus Super Mario Galaxy arrives tomorrow so its time for
a break.
Some highlights of this release:
- you might notice that some eager load operations are suddenly a lot
faster, particularly on MySQL. This is because we've improved the
queries that are issued when you use eager loading with LIMIT and/or
OFFSET; whereas we previously would wrap the LIMITed query in a
subquery, join back to the mapped table, and then add the eager
criterion outer joined against the mapped table, a trick we've been
doing since 0.1.0, we now outer join the eager criterion directly
against the subquery, and the main mapper pulls rows straight from the
subquery columns. Improved SQL expression functionality has allowed
this to be possible. What it means is, an eager load with LIMIT/
OFFSET uses one less JOIN in all cases. This is an example of SA's
very rich expression constructs paying off - since a query that is
much more efficient on the database side trumps the hundred or so
method calls spent compiling the query anyday.
- session.refresh() and session.expire() can now operate on individual
instance attributes. Just say session.expire(myobject, ['items',
'description', 'name']), and all three of those attributes, whether
they're just columns or relations to other objects, will go blank
until you next access them on the instance, at which point they are
refreshed from the DB. Column attributes will be grouped together in
a single select() statement and related tables will be lazy loaded
individually right now. Also, the internal mechanisms used by
deferred() columns, refresh/expire operations, and polymorphically
deferred columns have all been merged into one system, which means
less internal complexity and more consistent behavior.
- the API of the session has been hardened. This means its going to
check more closely that operations make sense (and it also no longer
raises some errors that did not make sense in certain circumstances).
The biggest gotcha we've observed so far from people using trunk is
that session.save() is used *only* for entities that have not been
saved to the database yet. If you put an already-stored instance in
save(), you'll get an error. This has always been the contract, it
just hasn't complained previously. If you want to put things in the
session without caring if they've already been saved or not, use
session.save_or_update(myinstance). We've also fixed things regarding
entities that have been de-pickled and placed back into the session -
some annoying errors that used to occur have been fixed.
- still in the session category, the merge() method gets a
dont_load=True argument. Everyone using caches like memcached can
now place copies of their cached objects back in the session using
myinstance = merge(mycachedinstance, dont_load=True), and the
instance will be fully copied as though it were loaded from the
database, *without* a load operation proceeding; it will trust that
you want that instance state in the session.
- query.options() are way more intelligent. Suppose you have a large
bidirectional chain of relations. If you say something like
query.options(eagerload('orders.items.keywords.items.orders')), it
will accurately target the 'orders' relation at the end of that chain
and nothing else. On a similar topic, self-referential eagerloads can
be set up on the fly, such as
query.options(eagerload_all('children.children.children')) without
needing to set the join_depth flag on relation().
- method call overhead continues to be cut down. Many expensive calls
in statement compilation, clauseelement construction, and statement
execution have been whacked away completely and replaced with simpler
and more direct behaviors, and results are more accurate and correct.
This continues along from all that we've done in 0.4 and at this point
most call counts should be half of what they were in 0.3. I invite
everyone to take a tour around expression.py, compiler.py, and
critique; we've had a huge amount of housecleaning in these modules
(and others), and further suggestions/ideas/flames are entirely
welcome (though not too early in the morning) on sqlalchemy-devel.
- in the fringe category, you can now define methods like __hash__(),
__nonzero__(), and __eq__() on your mapped instances and the ORM won't
get confused; we've rearranged things so that those methods are not
accessed by the ORM.
- a
