[sqlalchemy] Re: SQLAlchemy 0.4beta6 released !!

2007-09-27 Thread Michael Bayer


On Sep 27, 2007, at 12:17 AM, Jose Galvez wrote:


 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

you might be able to get away with that, but its still a good idea to  
call Session.remove() at the end of a request since its not a  
guarantee that things wont be lying around from the previous request.


--~--~-~--~~~---~--~~
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.4beta6 released !!

2007-09-27 Thread jose

Thanks for the info and thanks for some great software
Jose

On Sep 27, 8:03 am, Michael Bayer [EMAIL PROTECTED] wrote:
 On Sep 27, 2007, at 12:17 AM, Jose Galvez wrote:



  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

 you might be able to get away with that, but its still a good idea to
 call Session.remove() at the end of a request since its not a
 guarantee that things wont be lying around from the previous request.


--~--~-~--~~~---~--~~
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.4beta6 released !!

2007-09-26 Thread Jose Galvez

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