Hey I've been busy and haven't had a chance to comment on the 0.4.2 release yet.
Just wanted to give a big congrats on this release. I know it's one of the few releases out that have spawned an "a" (and looks like a forthcoming "b") interim releases, but aside from those issues, it's a really nice release. Getting rid of lazy loads on backref operations was a huge win in my app: I saw speed-up times of upwards of 30% nearly across the board, with no regressions. The library continues to impress and I'm really glad to see this kind of development pace maintained even after years into the project. Makes me feel like I climbed on the right horse way back in the pre-0.1days. Thanks yet again to Mike and to the rest of the team! On 1/2/08, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > hey all and happy new year - > > I've just put out 0.4.2, a release that's a lot bigger than a point > release would usually be. I've been kind of procrastinating with it, > since we're in this phase where the source to SA is changing somewhat > dramatically and a lot of old crufty things are being replaced with > simpler ideas that do more and work better...while this was the main > idea when we went from 0.3 to 0.4, it still continues. With this > release we kept going and going....and there's still a bunch more > things I want to do ! > > This release has a serious chunk of new features and other less > noticeable things intended increase efficiency and/or improve > behavior. Of the less noticeable things, the methodology used for > attribute history tracking has changed from copy-on-load to copy-on- > write (cuts down on ORM load times by about 25%), a new "generic > functions" mechanism has been added which, while its only used a > little bit so far, will eventually lead to better behavior of func.XXX > constructs with regards to typing behavior and such, and the way > mappers are linked to their classes has changed to be simpler and more > efficient, as well as self-dereferencing. Another big one is that > backref operations don't trigger lazy loads anymore; the changes to > the reverse side of a relation are queued up if and when the reverse > side actually loads. Still more, reconnect support was still a little > flaky in 0.4.1 and has been fixed and unit tested like mad, adding the > ability for a Connection to reconnect on its own; reconnect support > was also added to Oracle. For the caching-enthused, you can > pickle.dumps() any mapped instance, loads() it back, and all of its > deferred/lazy/expired attribute loaders, even if they were set at the > instance level via query.options() will remain intact; all the loaders > are now serializable (plus unit tests galore). The unit of work's > internals have been refactored significantly for clarity and decreased > complexity. > > Big noticeable things include, mutable primary keys - change the > primary key of an instance and flush(). There's some complexity to > deal with if you have foreign keys referencing that PK, namely that > you need to configure "ON UPDATE" cascades for a database that > enforces FK integrity. For a non-FK enforcing database like sqlite or > mysql MyISAM, you can set "cascade_updates=True" on relation() and > SQLAlchemy will cascade the primary key change on its own, along > mapped relationships. > > Another noticeable thing is that the Unicode type will issue a warning > if you send a plain string to it; note that the Unicode type as well > as flags like convert_unicode=True are meant to shuttle your Python > unicode objects to the database using the db's native encoding; they > are not intended to decode your application's raw Python > bytestrings ! So now the assert_unicode flag, which is configurable > as an error, warning (the default on Unicode), or neither (the default > on String/engine), will let you know about that. > > synonym() has been totally overhauled to be way more usable. Check > the docs on the site for this; you can now just set up your class- > level property(), and just set up a synonym() on the mapper which will > move the column out of the way for you in one step, and will also add > the SQL-clause instrumentation to your property(), so saying > MyClass.myprop == "foo" works just fine. > > Query.select_from() is a whole new animal now; you can literally put > *any select statement* into it (now as a scalar argument), and > continue to filter(), join(), and order_by(); all the criterion will > be properly aliased against the selectable as though it were the > mapped table. I wanted to go further with this, i.e. using the same > methodology for polymorphic loads and also creating "sub-queries" of > queries, but that stuff will be out in 0.4.3 and subsequent > releases. Query has been refined in this release, particularly the > instances() method (the main method that loads instances from a > cursor), but still has some major things to be done (including fixing > up count(), max(), min(), etc., yes I know these need work! - ticket > 876). > > We also have a much easier-to-use TypeDecorator class; also see the > docs on the site for that. > > As usual tons of bugs have been fixed too and I hope that a decent > number of users are already on this version via SVN since we've hit > upon a good number of them since 0.4.1 (and a good number are still in > pending in trac). > > Changelog at http://www.sqlalchemy.org/CHANGES , download at > http://www.sqlalchemy.org/download.html . > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
