thanks, this is fixed in r5970 and I may release 0.5.4p1 today.
On May 18, 2009, at 11:54 AM, Francesca Leon wrote: > Sorry, here it is: > > Traceback (most recent call last): > File "C:\dex\python\dex\tests\adrims\TestDataBase.py", line 973, > in testMerge_SomethingThatNeverExisted > self.session.flush() > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\session.py", line 1354, in flush > self._flush(objects) > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\session.py", line 1432, in _flush > flush_context.execute() > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\unitofwork.py", line 257, in execute > UOWExecutor().execute(self, tasks) > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\unitofwork.py", line 720, in execute > self.execute_save_steps(trans, task) > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\unitofwork.py", line 735, in execute_save_steps > self.save_objects(trans, task) > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\unitofwork.py", line 726, in save_objects > task.mapper._save_obj(task.polymorphic_tosave_objects, trans) > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\mapper.py", line 1313, in _save_obj > value = mapper._get_state_attr_by_column(state, col) > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\mapper.py", line 1082, in _get_state_attr_by_column > return self._get_col_to_prop(column).getattr(state, column) > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\properties.py", line 99, in getattr > return state.get_impl(self.key).get(state, state.dict) > File "c:\python25\lib\site-packages\SQLAlchemy-0.5.4-py2.5.egg > \sqlalchemy\orm\attributes.py", line 379, in get > return self.get(state, passive=passive) > TypeError: get() takes at least 3 non-keyword arguments (2 given) > > > Michael Bayer wrote: >> >> >> On May 18, 2009, at 11:38 AM, Francesca Leon wrote: >> >>> May be I'm doing something weird... Anyway: I tried to "merge" on >>> a not existing object, like this: >>> >>> session.merge(myObject) >>> session.flush() # where "autoflush" is disabled on session >>> >>> The exception is triggered by the "flush" action. >>> "MyObject" is mapped on a table with some not nullable foreign keys. >>> >>> With SqlAlchemy 0.5.2 this is working as expected, in particular: >>> * before the "merge"/"flush" actions no rows are present into the >>> table; >>> * after the "merge"/"flush" actions, I find one new row added to >>> the table. >> >> but, what are you doing to trigger the stack trace you mentioned >> earlier ? can I see that entire stack trace please ? >> >> >> >>> >>> >>> Hope this helps. >>> Thank you again >>> >>> >>> Michael Bayer wrote: >>>> >>>> Francesca Leon wrote: >>>> >>>>> Hi Michael >>>>> >>>>> I just downloaded version 0.5.4 of SqlAlchemy. >>>>> I would like to signal just a small detail that seems to make my >>>>> tests >>>>> fail: >>>>> >>>>> [...] >>>>> File >>>>> "C:\Python25\lib\site-packages\sqlalchemy-0.5.4-py2.5.egg >>>>> \sqlalchemy\orm\attributes.py", >>>>> line 379, in get >>>>> return self.get(state, passive=passive) >>>>> TypeError: get() takes at least 3 non-keyword arguments (2 given) >>>>> >>>>> Thank you for all your great work! >>>>> >>>> thats an internal API that has changed. What are you doing to >>>> trigger it ? >>>> >>>> >>>> >>>> >>>> >>>>> Francesca >>>>> >>>>> >>>>> Michael Bayer wrote: >>>>> >>>>>> Hello list - >>>>>> >>>>>> SQLAlchemy 0.5.4 is released, and this release is *highly* >>>>>> recommended >>>>>> for all users. For an indication of how high, lets just say, >>>>>> higher >>>>>> than 0.5.3, 0.5.2, and 0.5.1combined. >>>>>> >>>>>> Not to worry, there are no security holes or memory leaks in >>>>>> previous >>>>>> versions. But we have neutralized some major, major speed >>>>>> bumps in >>>>>> the flush() process, as well as made significant improvements to >>>>>> memory usage. Due to the removal of these bugs, large dataset >>>>>> scenarios that were more or less impossible to work with for any >>>>>> version of SQLAlchemy now run at top speed with the same rate >>>>>> performance regardless of how large the Session grows. Other >>>>>> performance issues that were proportional to the number of >>>>>> interconnected mapped classes, memory/speed issues related to the >>>>>> number of relation()s set up on mappers during a load, or just >>>>>> wasteful overhead during the flush have been mitigated. The >>>>>> improvements are of a magnitude such that some applications >>>>>> that had >>>>>> abaondoned the ORM due to latency related to large sets of >>>>>> objects may >>>>>> be able to come back to it and regain all its advantages. >>>>>> >>>>>> The key to all these improvements is, that i finally have a job >>>>>> using >>>>>> SQLAlchemy full time where I've gotten the opportunity to use >>>>>> the ORM >>>>>> with somewhat large amounts of data. None of these issues >>>>>> were very >>>>>> deep and just required that I spend some more time with the >>>>>> profiler >>>>>> and bigger datasets. My own use case here is a 6500 row >>>>>> spreadsheet >>>>>> of interconnected objects, representing about 25K rows - the >>>>>> process >>>>>> of ingesting that data, which requires that all of the objects >>>>>> need to >>>>>> stay present in the session, has gone from 33 minutes to 8. >>>>>> The >>>>>> key is that the number of method calls to flush X number of >>>>>> objects is >>>>>> now the same for a session regardless of how many other non-dirty >>>>>> items are present. Similarly, a mapping setup that has 30 >>>>>> mappers >>>>>> configured will not be slowed down by unnecessary traversal of >>>>>> all the >>>>>> mapper relations. >>>>>> >>>>>> The Session itself, which has for some time now has been "weak >>>>>> referencing" with regards to its contents, has been repaired >>>>>> such that >>>>>> the weak referencing behavior is now fully operational. >>>>>> Previously, >>>>>> objects which were related via mutual backrefs would not get >>>>>> cleared >>>>>> from the session when all external references were lost until you >>>>>> expunged them. That is no longer necessary - the Session >>>>>> now has >>>>>> no strong references whatsoever to its contents, as long as no >>>>>> changes >>>>>> are pending on those objects. Pending changes as always are >>>>>> strongly >>>>>> referenced until flushed. So now you can iterate through as >>>>>> many >>>>>> tens of thousands of objects as you like (keeping in mind an >>>>>> individual Query still loads each individual result fully in >>>>>> unless >>>>>> yield_per is enabled) and there's no need to expunge the >>>>>> session in >>>>>> between chunks. >>>>>> >>>>>> The loading of objects has also been sped up and reduced in >>>>>> memory >>>>>> overhead by killing a wasteful structure of callables that was >>>>>> generated on a per-relation()/per-object basis whenever >>>>>> query.options() was used. >>>>>> >>>>>> In other news I've backported a convenient extension from the 0.6 >>>>>> series which allows you to create custom SQL expression >>>>>> elements with >>>>>> compiler functions. This is the "compiler" extension and is >>>>>> described in the documentation. >>>>>> >>>>>> Download SQLAlchemy 0.5.4 (right now !! get rid of whatever >>>>>> buggy old >>>>>> version you're using) at: >>>>>> >>>>>> http://www.sqlalchemy.org/download.html >>>>>> >>>>>> >>>>>> 0.5.4 >>>>>> ===== >>>>>> >>>>>> - orm >>>>>> - Significant performance enhancements regarding Sessions/ >>>>>> flush() >>>>>> in conjunction with large mapper graphs, large numbers of >>>>>> objects: >>>>>> >>>>>> - Removed all* O(N) scanning behavior from the flush() >>>>>> process, >>>>>> i.e. operations that were scanning the full session, >>>>>> including an extremely expensive one that was >>>>>> erroneously >>>>>> assuming primary key values were changing when this >>>>>> was not the case. >>>>>> >>>>>> * one edge case remains which may invoke a full scan, >>>>>> if an existing primary key attribute is modified >>>>>> to a new value. >>>>>> >>>>>> - The Session's "weak referencing" behavior is now >>>>>> *full* - >>>>>> no strong references whatsoever are made to a mapped >>>>>> object >>>>>> or related items/collections in its __dict__. >>>>>> Backrefs and >>>>>> other cycles in objects no longer affect the Session's >>>>>> ability >>>>>> to lose all references to unmodified objects. Objects >>>>>> with >>>>>> pending changes still are maintained strongly until >>>>>> flush. >>>>>> [ticket:1398] >>>>>> >>>>>> The implementation also improves performance by moving >>>>>> the "resurrection" process of garbage collected items >>>>>> to only be relevant for mappings that map "mutable" >>>>>> attributes (i.e. PickleType, composite attrs). This >>>>>> removes >>>>>> overhead from the gc process and simplifies internal >>>>>> behavior. >>>>>> >>>>>> If a "mutable" attribute change is the sole change on >>>>>> an object >>>>>> which is then dereferenced, the mapper will not have >>>>>> access to >>>>>> other attribute state when the UPDATE is issued. This >>>>>> may >>>>>> present >>>>>> itself differently to some MapperExtensions. >>>>>> >>>>>> The change also affects the internal attribute API, >>>>>> but not >>>>>> the AttributeExtension interface nor any of the >>>>>> publically >>>>>> documented attribute functions. >>>>>> >>>>>> - The unit of work no longer genererates a graph of >>>>>> "dependency" >>>>>> processors for the full graph of mappers during flush(), >>>>>> instead >>>>>> creating such processors only for those mappers which >>>>>> represent >>>>>> objects with pending changes. This saves a tremendous >>>>>> number >>>>>> of method calls in the context of a large interconnected >>>>>> graph of mappers. >>>>>> >>>>>> - Cached a wasteful "table sort" operation that previously >>>>>> occured multiple times per flush, also removing >>>>>> significant >>>>>> method call count from flush(). >>>>>> >>>>>> - Other redundant behaviors have been simplified in >>>>>> mapper._save_obj(). >>>>>> >>>>>> - Modified query_cls on DynamicAttributeImpl to accept a >>>>>> full >>>>>> mixin version of the AppenderQuery, which allows >>>>>> subclassing >>>>>> the AppenderMixin. >>>>>> >>>>>> - The "polymorphic discriminator" column may be part of a >>>>>> primary key, and it will be populated with the correct >>>>>> discriminator value. [ticket:1300] >>>>>> >>>>>> - Fixed the evaluator not being able to evaluate IS NULL >>>>>> clauses. >>>>>> >>>>>> - Fixed the "set collection" function on "dynamic" >>>>>> relations to >>>>>> initiate events correctly. Previously a collection >>>>>> could only >>>>>> be assigned to a pending parent instance, otherwise >>>>>> modified >>>>>> events would not be fired correctly. Set collection is >>>>>> now >>>>>> compatible with merge(), fixes [ticket:1352]. >>>>>> >>>>>> - Allowed pickling of PropertyOption objects constructed >>>>>> with >>>>>> instrumented descriptors; previously, pickle errors >>>>>> would occur >>>>>> when pickling an object which was loaded with a >>>>>> descriptor-based >>>>>> option, such as query.options(eagerload(MyClass.foo)). >>>>>> >>>>>> - Lazy loader will not use get() if the "lazy load" SQL >>>>>> clause >>>>>> matches the clause used by get(), but contains some >>>>>> parameters >>>>>> hardcoded. Previously the lazy strategy would fail with >>>>>> the >>>>>> get(). Ideally get() would be used with the hardcoded >>>>>> parameters but this would require further development. >>>>>> [ticket:1357] >>>>>> >>>>>> - MapperOptions and other state associated with >>>>>> query.options() >>>>>> is no longer bundled within callables associated with each >>>>>> lazy/deferred-loading attribute during a load. >>>>>> The options are now associated with the instance's >>>>>> state object just once when it's populated. This removes >>>>>> the need in most cases for per-instance/attribute loader >>>>>> objects, improving load speed and memory overhead for >>>>>> individual instances. [ticket:1391] >>>>>> >>>>>> - Fixed another location where autoflush was interfering >>>>>> with session.merge(). autoflush is disabled completely >>>>>> for the duration of merge() now. [ticket:1360] >>>>>> >>>>>> - Fixed bug which prevented "mutable primary key" dependency >>>>>> logic from functioning properly on a one-to-one >>>>>> relation(). [ticket:1406] >>>>>> >>>>>> - Fixed bug in relation(), introduced in 0.5.3, >>>>>> whereby a self referential relation >>>>>> from a base class to a joined-table subclass would >>>>>> not configure correctly. >>>>>> >>>>>> - Fixed obscure mapper compilation issue when inheriting >>>>>> mappers are used which would result in un-initialized >>>>>> attributes. >>>>>> >>>>>> - Fixed documentation for session weak_identity_map - >>>>>> the default value is True, indicating a weak >>>>>> referencing map in use. >>>>>> >>>>>> - Fixed a unit of work issue whereby the foreign >>>>>> key attribute on an item contained within a collection >>>>>> owned by an object being deleted would not be set to >>>>>> None if the relation() was self-referential. [ticket:1376] >>>>>> >>>>>> - Fixed Query.update() and Query.delete() failures with >>>>>> eagerloaded >>>>>> relations. [ticket:1378] >>>>>> >>>>>> - It is now an error to specify both columns of a binary >>>>>> primaryjoin >>>>>> condition in the foreign_keys or remote_side >>>>>> collection. Whereas >>>>>> previously it was just nonsensical, but would succeed in a >>>>>> non-deterministic way. >>>>>> >>>>>> - schema >>>>>> - Added a quote_schema() method to the IdentifierPreparer >>>>>> class >>>>>> so that dialects can override how schemas get handled. >>>>>> This >>>>>> enables the MSSQL dialect to treat schemas as multipart >>>>>> identifiers, such as 'database.owner'. [ticket: 594, 1341] >>>>>> >>>>>> - sql >>>>>> - Back-ported the "compiler" extension from SQLA 0.6. This >>>>>> is a standardized interface which allows the creation of >>>>>> custom >>>>>> ClauseElement subclasses and compilers. In particular >>>>>> it's >>>>>> handy as an alternative to text() when you'd like to >>>>>> build a construct that has database-specific compilations. >>>>>> See the extension docs for details. >>>>>> >>>>>> - Exception messages are truncated when the list of bound >>>>>> parameters is larger than 10, preventing enormous >>>>>> multi-page exceptions from filling up screens and logfiles >>>>>> for large executemany() statements. [ticket:1413] >>>>>> >>>>>> - ``sqlalchemy.extract()`` is now dialect sensitive and can >>>>>> extract components of timestamps idiomatically across the >>>>>> supported databases, including SQLite. >>>>>> >>>>>> - Fixed __repr__() and other _get_colspec() methods on >>>>>> ForeignKey constructed from __clause_element__() style >>>>>> construct (i.e. declarative columns). [ticket:1353] >>>>>> >>>>>> - mysql >>>>>> - Reflecting a FOREIGN KEY construct will take into account >>>>>> a dotted schema.tablename combination, if the foreign key >>>>>> references a table in a remote schema. [ticket:1405] >>>>>> >>>>>> - mssql >>>>>> - Modified how savepoint logic works to prevent it from >>>>>> stepping on non-savepoint oriented routines. Savepoint >>>>>> support is still very experimental. >>>>>> >>>>>> - Added in reserved words for MSSQL that covers version 2008 >>>>>> and all prior versions. [ticket:1310] >>>>>> >>>>>> - Corrected problem with information schema not working >>>>>> with a >>>>>> binary collation based database. Cleaned up information >>>>>> schema >>>>>> since it is only used by mssql now. [ticket:1343] >>>>>> >>>>>> - sqlite >>>>>> - Corrected the SLBoolean type so that it properly treats >>>>>> only 1 >>>>>> as True. [ticket:1402] >>>>>> >>>>>> - Corrected the float type so that it correctly maps to a >>>>>> SLFloat type when being reflected. [ticket:1273] >>>>>> >>>>>> - extensions >>>>>> >>>>>> - Fixed adding of deferred or other column properties to a >>>>>> declarative class. [ticket:1379] >>>>>> >>>>>> - Added "compiler" extension from 0.6 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
