Dear Micheal, Does this mean that with web apps since the session is now "weak referencing" that we will no longer have to call Session.remove() to clear out Sessions? Specifically I'm referencing what Mike Orr wrote in the pylonscookbook. Jose
Michael Bayer wrote: > This should hopefully be the last of the beta releases before 0.4.0 > is released. The big change in this one is that the ORM Session is > now *weak referencing* by default, with an option to turn on the old > "strong referencing" behavior. This means that objects in the > session get cleared out automatically when they fall out of scope > within your application. Objects which have pending changes on them > will not get cleared until the session is flushed. > > Theres also some refinements to how mappers compile, and it should be > much less likely that you'd get stuck with an uncompiled mapper. > When defining mappers in an inheritance relationship, the superclass > mapper needs to be defined before the corresponding subclass mappers > (which should be how everyone is doing it anyway...I think). Other > than that you can still define mappers in whatever order regardless > of relations to each other. > > Besides those, we have a lot of bug fixes and some more enhancements > and speed improvements. We mainly want to see that this one is > stable, works in everyone's environment as well or better than all > the other betas, and then we should be ready to go. > > Download 0.4 beta6 at: > > http://www.sqlalchemy.org/download.html > > changelog (also at http://www.sqlalchemy.org/CHANGES) : > > 0.4.0beta6 > ---------- > > - The Session identity map is now *weak referencing* by default, use > weak_identity_map=False to use a regular dict. The weak dict we > are using > is customized to detect instances which are "dirty" and maintain a > temporary strong reference to those instances until changes are > flushed. > > - Mapper compilation has been reorganized such that most compilation > occurs > upon mapper construction. This allows us to have fewer calls to > mapper.compile() and also to allow class-based properties to force a > compilation (i.e. User.addresses == 7 will compile all mappers; > this is > [ticket:758]). The only caveat here is that an inheriting mapper now > looks for its inherited mapper upon construction; so mappers within > inheritance relationships need to be constructed in inheritance order > (which should be the normal case anyway). > > - added "FETCH" to the keywords detected by Postgres to indicate a > result-row holding statement (i.e. in addition to "SELECT"). > > - Added full list of SQLite reserved keywords so that they get escaped > properly. > > - Tightened up the relationship between the Query's generation of "eager > load" aliases, and Query.instances() which actually grabs the eagerly > loaded rows. If the aliases were not specifically generated for that > statement by EagerLoader, the EagerLoader will not take effect > when the > rows are fetched. This prevents columns from being grabbed > accidentally > as being part of an eager load when they were not meant for such, > which > can happen with textual SQL as well as some inheritance > situations. It's > particularly important since the "anonymous aliasing" of columns uses > simple integer counts now to generate labels. > > - Removed "parameters" argument from clauseelement.compile(), > replaced with > "column_keys". The parameters sent to execute() only interact > with the > insert/update statement compilation process in terms of the column > names > present but not the values for those columns. Produces more > consistent > execute/executemany behavior, simplifies things a bit internally. > - Added 'comparator' keyword argument to PickleType. By default, > "mutable" > PickleType does a "deep compare" of objects using their dumps() > representation. But this doesn't work for dictionaries. Pickled > objects > which provide an adequate __eq__() implementation can be set up with > "PickleType(comparator=operator.eq)" [ticket:560] > > - Added session.is_modified(obj) method; performs the same "history" > comparison operation as occurs within a flush operation; setting > include_collections=False gives the same result as is used when > the flush > determines whether or not to issue an UPDATE for the instance's row. > > - Added "schema" argument to Sequence; use this with Postgres /Oracle > when > the sequence is located in an alternate schema. Implements part of > [ticket:584], should fix [ticket:761]. > > - Fixed reflection of the empty string for mysql enums. > > - Changed MySQL dialect to use the older LIMIT <offset>, <limit> syntax > instead of LIMIT <l> OFFSET <o> for folks using 3.23. [ticket:794] > > - Added 'passive_deletes="all"' flag to relation(), disables all > nulling-out > of foreign key attributes during a flush where the parent object is > deleted. > > - Column defaults and onupdates, executing inline, will add > parenthesis for > subqueries and other parenthesis-requiring expressions > > - The behavior of String/Unicode types regarding that they auto- > convert to > TEXT/CLOB when no length is present now occurs *only* for an exact > type of > String or Unicode with no arguments. If you use VARCHAR or NCHAR > (subclasses of String/Unicode) with no length, they will be > interpreted by > the dialect as VARCHAR/NCHAR; no "magic" conversion happens > there. This > is less surprising behavior and in particular this helps Oracle keep > string-based bind parameters as VARCHARs and not CLOBs [ticket:793]. > > - Fixes to ShardedSession to work with deferred columns [ticket:771]. > > - User-defined shard_chooser() function must accept "clause=None" > argument; > this is the ClauseElement passed to session.execute(statement) and > can be > used to determine correct shard id (since execute() doesn't take an > instance.) > > - Adjusted operator precedence of NOT to match '==' and others, so that > ~(x <operator> y) produces NOT (x <op> y), which is better compatible > with older MySQL versions. [ticket:764]. This doesn't apply to "~ > (x==y)" > as it does in 0.3 since ~(x==y) compiles to "x != y", but still > applies > to operators like BETWEEN. > > - Other tickets: [ticket:768], [ticket:728], [ticket:779], [ticket:757] > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
