[sqlalchemy] Re: Selecting from a self-referential mapper: recursive joins?

[az]

u can look at my posts on the topic and all related too (-:) 
search for recursive/recursion/graph/sets

in short:

 - storage:
   - store graph in pure form (nodes/edges only) - easy to 
maintain/update, very difficult to query 
   - store some preprocessed (cached) denormalized form (all paths per 
node or all reachable nodes or ...) - hard/expensive to 
maintain/update, easy for some queries, hard for others - depends on 
the form used; 

 - retrieving:
   - try making sql do the recursive stuff for yourself - not very 
scalable unless u use recursive sql (??)
   - do recursion yourself and load one level at a time - can be slow; 
i.e. 10 levels = 10 queries
   - load whole thing and do all math in memory - may or may not be 
feasible

10 nodes deep is a lot. i mean, if u store only pure nodes and edges, 
and need to find the paths/stuff related to A1, it would be like:
 A1 and stuff-there
or
 A1 - A1' and stuff-there
or
 A1 - A1 - A1' and stuff-there
or ...
which will make all these appear in FROM clause...; u can make a union 
of these to avoid FROM explosion but still this has to be expanded 
beforehand, as plain sql is not recursive (well some sqls are).

so u have to store the graph in denormalized/cached form - nested sets 
or whatever was the other way; i.e. u do the recursive graph math 
(using kjbuckets or similar) before saving and save the intermediate 
non-recursive (and possibly repeating) results. Depending on what 
queries u need u can/should store different stuff - e.g. storing _all 
reachable nodes per node gives u ability for certain class of 
queries, other things give u other abilities - think of it like 
moving down one direction and not another. Choosing which 
representation also depends on cost of updating it - adding one node 
or one edge may cause updating 99% of the data.

u can also store the graph in pure form, and use sql only as storage, 
i.e. always load the whole graph, do the recursive math yourself, 
then query the db for extra data, according to results. i have one 
working case where this is much faster/easier than any other approach 
(users/roles/modules/funcs and permissions across each/all of these).

although sql is about sets math internaly, that part of it isn't very 
popular and well developed - apart of having union, intersection, 
substract etc operators. at least i could not find a reasonable way 
to make it do my set arithmetics... well, i'm not sql guru at all, 
just using it as the least evil ;-).

ciao
svilen
www.svilendobrev.com

On Saturday 17 January 2009 06:15:00 rich wrote:
 Eric,

 Any additional conclusions to recursively querying your dependency
 graph?  I just found SA, and have been wondering how feasible it
 would be to manage and query a graph structure somewhat similar to
 the one you've described.  My problem is that I have a number of
 classes that build expensive data attributes, each of which is one
 step to producing many possible different solutions.  The classes
 are organized so that all attributes built by that class depend on
 the same set of parameters, so that if I know the set of parameter
 values, I know that all of the data attributes built by that class
 are congruent.  As each class instance performs one or more
 transformations, it needs to be able to retrieve the correct data
 structures, i.e. those that have been built with the same parameter
 values.

 Currently I keep the data attributes in python shelves, which I
 plan on continue doing, as they are too large to stick in sql
 (numpy arrays of up to a Gb or two), and manage a half-baked sql db
 to track the class instances, their parameter values, and shelf
 file names.  I want to use SA to manage the shelf file names and
 directories by mirroring the dependency structure of the classes.

 The problem is that there are a bunch of parameters, and the more
 dependent the classes become (deep children in a graph), the more
 parameter values are needed to exactly define the data attributes. 
 In addition, I don't know the complete dependency structure until
 run- time, as some classes can depend on an arbitrary number of
 other classes (these other classes have different methods to
 produce the needed data).

 If SA could manage a dependency graph as I build the data
 attributes, I could then query it to check whether a needed data
 attribute with the right specifications already existed, and in
 which shelf in which directory (one shelf per class instance
 holding the keyed data attributes).  Each class instance would not
 need to store the parameter values of all the class instances it
 depended on (there may be scores of such parameter values), but
 only a small subset directly used by its methods, as a query could
 traverse the graph and check which parameter values had been used
 at each step.

 I thought if I made a simple class structure that mirrored my
 working classes that all inherited from a class that would serve as
 nodes in the graph, that I might be able 

[sqlalchemy] session.merge()

[n00b]

greetings,

i'm batch processing xml documents to mysql using SA 0.5, ORM.

data extracted from xml docs may be new or an update in form of a
replacement of
the existing object (record). (one of the columns, product_id, is
unique=True). Hence,
SA throws, as expected, an IntegrityError (1062, duplicate Entry) when
i'm trying to commit the revised object via session.add(obj),
session.commit().

given the xml volume at hand, i thought i could use session.merge
rather than query every time for existence. alas, no go. get the same
1062 exception. obviously, i don't understand the session merge.

in fact, even if i query for the existence, then try and assign the
new object to the existing object (old_obj = session.query(OBJ).filter
(OBJ.product_id == new_obj.product.id).one(), old_obj = new_obj,
session.add(old_obj), session.commit()), i get the dreaded 1062.

any insights/suggestions?

thx
--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: Migrating objects across sessions

[Darren Govoni]

After some further experimenting with this, it seems I cannot take a
mapped object I retrieved from one session and save it in another.

Using expunge then adding the object to a second session on a different
database does not work. I thought maybe it would.

This is a really useful thing to do, especially for replication at the
object layer.

So is it true that this cannot currently be done with sqlalchemy? I have
been reading the docs, but no clues yet.

On Fri, 2009-01-16 at 16:53 -0500, Darren Govoni wrote:
 Hi,
  I have an object (with references) I get from a session on database A
 and I want to copy it (deep copy) to database B. I tried expunging it
 from the first session and adding it to the second. What's the best
 practice to do this?
 
 thanks!
 Darren
 
 
  


--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: Migrating objects across sessions

[az]

read various threads about copy/deep-copy.
in any case u'll have to do the hierarchy-copying yourself - even if 
moving one object (alone) from session to session succeeds somehow.

On Saturday 17 January 2009 14:47:41 Darren Govoni wrote:
 After some further experimenting with this, it seems I cannot take
 a mapped object I retrieved from one session and save it in
 another.

 Using expunge then adding the object to a second session on a
 different database does not work. I thought maybe it would.

 This is a really useful thing to do, especially for replication at
 the object layer.

 So is it true that this cannot currently be done with sqlalchemy? I
 have been reading the docs, but no clues yet.

 On Fri, 2009-01-16 at 16:53 -0500, Darren Govoni wrote:
  Hi,
   I have an object (with references) I get from a session on
  database A and I want to copy it (deep copy) to database B. I
  tried expunging it from the first session and adding it to the
  second. What's the best practice to do this?
 
  thanks!
  Darren

--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: Migrating objects across sessions

[Darren Govoni]

Yes, i'd like to do that, but because of the code injection seems to
carry state from the old session, the new session has trouble with even
the copy.

On Sat, 2009-01-17 at 15:23 +0200, a...@svilendobrev.com wrote:
 read various threads about copy/deep-copy.
 in any case u'll have to do the hierarchy-copying yourself - even if 
 moving one object (alone) from session to session succeeds somehow.
 
 On Saturday 17 January 2009 14:47:41 Darren Govoni wrote:
  After some further experimenting with this, it seems I cannot take
  a mapped object I retrieved from one session and save it in
  another.
 
  Using expunge then adding the object to a second session on a
  different database does not work. I thought maybe it would.
 
  This is a really useful thing to do, especially for replication at
  the object layer.
 
  So is it true that this cannot currently be done with sqlalchemy? I
  have been reading the docs, but no clues yet.
 
  On Fri, 2009-01-16 at 16:53 -0500, Darren Govoni wrote:
   Hi,
I have an object (with references) I get from a session on
   database A and I want to copy it (deep copy) to database B. I
   tried expunging it from the first session and adding it to the
   second. What's the best practice to do this?
  
   thanks!
   Darren
 
  


--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: Migrating objects across sessions

[Darren Govoni]

I tried using session.merge(deepcopy) on my copy.deepcopy of a mapped
object(s) and when I commit the session I get

RuntimeError: maximum recursion depth exceeded

strange.

On Sat, 2009-01-17 at 15:23 +0200, a...@svilendobrev.com wrote:
 read various threads about copy/deep-copy.
 in any case u'll have to do the hierarchy-copying yourself - even if 
 moving one object (alone) from session to session succeeds somehow.
 
 On Saturday 17 January 2009 14:47:41 Darren Govoni wrote:
  After some further experimenting with this, it seems I cannot take
  a mapped object I retrieved from one session and save it in
  another.
 
  Using expunge then adding the object to a second session on a
  different database does not work. I thought maybe it would.
 
  This is a really useful thing to do, especially for replication at
  the object layer.
 
  So is it true that this cannot currently be done with sqlalchemy? I
  have been reading the docs, but no clues yet.
 
  On Fri, 2009-01-16 at 16:53 -0500, Darren Govoni wrote:
   Hi,
I have an object (with references) I get from a session on
   database A and I want to copy it (deep copy) to database B. I
   tried expunging it from the first session and adding it to the
   second. What's the best practice to do this?
  
   thanks!
   Darren
 
  


--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: Migrating objects across sessions

[az]

 Yes, i'd like to do that, but because of the code injection seems
 to carry state from the old session, the new session has trouble
 with even the copy.
then, separate the issues:
 a) make a working deep copy within same session (this is not at all 
trivial, except for very simple schemas)
 b) make a working move-across-session for singular obj
and just then combine

 On Sat, 2009-01-17 at 15:23 +0200, a...@svilendobrev.com wrote:
  read various threads about copy/deep-copy.
  in any case u'll have to do the hierarchy-copying yourself - even
  if moving one object (alone) from session to session succeeds
  somehow.
 
  On Saturday 17 January 2009 14:47:41 Darren Govoni wrote:
   After some further experimenting with this, it seems I cannot
   take a mapped object I retrieved from one session and save it
   in another.
  
   Using expunge then adding the object to a second session on a
   different database does not work. I thought maybe it would.
  
   This is a really useful thing to do, especially for replication
   at the object layer.
  
   So is it true that this cannot currently be done with
   sqlalchemy? I have been reading the docs, but no clues yet.
  
   On Fri, 2009-01-16 at 16:53 -0500, Darren Govoni wrote:
Hi,
 I have an object (with references) I get from a session on
database A and I want to copy it (deep copy) to database B. I
tried expunging it from the first session and adding it to
the second. What's the best practice to do this?
   
thanks!
Darren

 


--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: session.merge()

[Laurent Rahuel]

Hi,

Did you first load the entry to update into the session or do you  
always create new objects to be saved ?
I guess you need to:

1 - try to get the record from the database using the product_id or 
another unique field
2 - if the result set is not empty,
update the record using values from the XML and session.commit() 
will update the database
 else
create a new mapped object with values from the XML file, 
session.add(ob), and session.commit() will add the record into database

Regards,

Laurent


n00b a écrit :
 greetings,

 i'm batch processing xml documents to mysql using SA 0.5, ORM.

 data extracted from xml docs may be new or an update in form of a
 replacement of
 the existing object (record). (one of the columns, product_id, is
 unique=True). Hence,
 SA throws, as expected, an IntegrityError (1062, duplicate Entry) when
 i'm trying to commit the revised object via session.add(obj),
 session.commit().

 given the xml volume at hand, i thought i could use session.merge
 rather than query every time for existence. alas, no go. get the same
 1062 exception. obviously, i don't understand the session merge.

 in fact, even if i query for the existence, then try and assign the
 new object to the existing object (old_obj = session.query(OBJ).filter
 (OBJ.product_id == new_obj.product.id).one(), old_obj = new_obj,
 session.add(old_obj), session.commit()), i get the dreaded 1062.

 any insights/suggestions?

 thx
 

   


--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: session.merge()

[Michael Bayer]

On Jan 17, 2009, at 4:07 AM, n00b wrote:


 greetings,

 i'm batch processing xml documents to mysql using SA 0.5, ORM.

 data extracted from xml docs may be new or an update in form of a
 replacement of
 the existing object (record). (one of the columns, product_id, is
 unique=True). Hence,
 SA throws, as expected, an IntegrityError (1062, duplicate Entry) when
 i'm trying to commit the revised object via session.add(obj),
 session.commit().

 given the xml volume at hand, i thought i could use session.merge
 rather than query every time for existence. alas, no go. get the same
 1062 exception. obviously, i don't understand the session merge.

 in fact, even if i query for the existence, then try and assign the
 new object to the existing object (old_obj = session.query(OBJ).filter
 (OBJ.product_id == new_obj.product.id).one(), old_obj = new_obj,
 session.add(old_obj), session.commit()), i get the dreaded 1062.

 any insights/suggestions?

you're on the right track, except that merge() is basing its do i  
update an existing object based on primary keys, not just unique  
constraints.  you'd have to merge() objects that match up to those you  
want to update based on primary key.   if your tables don't look like  
that, you can still configure the mapper() to consider any arbitrary  
set of columns as primary key columns using the primary_key argument.

--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: session.merge()

[n00b]

thanks. i'll give it a shot.

On Jan 17, 10:43 am, Michael Bayer mike...@zzzcomputing.com wrote:
 On Jan 17, 2009, at 4:07 AM, n00b wrote:





  greetings,

  i'm batch processing xml documents to mysql using SA 0.5, ORM.

  data extracted from xml docs may be new or an update in form of a
  replacement of
  the existing object (record). (one of the columns, product_id, is
  unique=True). Hence,
  SA throws, as expected, an IntegrityError (1062, duplicate Entry) when
  i'm trying to commit the revised object via session.add(obj),
  session.commit().

  given the xml volume at hand, i thought i could use session.merge
  rather than query every time for existence. alas, no go. get the same
  1062 exception. obviously, i don't understand the session merge.

  in fact, even if i query for the existence, then try and assign the
  new object to the existing object (old_obj = session.query(OBJ).filter
  (OBJ.product_id == new_obj.product.id).one(), old_obj = new_obj,
  session.add(old_obj), session.commit()), i get the dreaded 1062.

  any insights/suggestions?

 you're on the right track, except that merge() is basing its do i  
 update an existing object based on primary keys, not just unique  
 constraints.  you'd have to merge() objects that match up to those you  
 want to update based on primary key.   if your tables don't look like  
 that, you can still configure the mapper() to consider any arbitrary  
 set of columns as primary key columns using the primary_key argument.
--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: session.merge()

[n00b]

actually, this is exactly what i didn't want to do .. at least not
explicitly. thx.

On Jan 17, 3:24 am, Laurent Rahuel laurent.rah...@gmail.com wrote:
 Hi,

 Did you first load the entry to update into the session or do you  
 always create new objects to be saved ?
 I guess you need to:

 1 - try to get the record from the database using the product_id or
 another unique field
 2 - if the result set is not empty,
         update the record using values from the XML and session.commit()
 will update the database
      else
         create a new mapped object with values from the XML file,
 session.add(ob), and session.commit() will add the record into database

 Regards,

 Laurent

 n00b a écrit :

  greetings,

  i'm batch processing xml documents to mysql using SA 0.5, ORM.

  data extracted from xml docs may be new or an update in form of a
  replacement of
  the existing object (record). (one of the columns, product_id, is
  unique=True). Hence,
  SA throws, as expected, an IntegrityError (1062, duplicate Entry) when
  i'm trying to commit the revised object via session.add(obj),
  session.commit().

  given the xml volume at hand, i thought i could use session.merge
  rather than query every time for existence. alas, no go. get the same
  1062 exception. obviously, i don't understand the session merge.

  in fact, even if i query for the existence, then try and assign the
  new object to the existing object (old_obj = session.query(OBJ).filter
  (OBJ.product_id == new_obj.product.id).one(), old_obj = new_obj,
  session.add(old_obj), session.commit()), i get the dreaded 1062.

  any insights/suggestions?

  thx
--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: Migrating objects across sessions

[Michael Bayer]

On Jan 17, 2009, at 1:46 PM, Darren Govoni wrote:


 Hi,
  Thanks for the suggestions. In my system, it is a federation of
 databases using SQLA as the object layer. There are message queues
 that move detched data around as needed. My goal is to keep the
 application as OO as possible with respect to interacting with the
 database, queuing etc. In these cases, objects are retrieved from some
 databases and need to be saved to others.

 there's a real benefit to not mixing and matching strategies since its
 real nice how SQLA already mitigates the complexities of SQL under
 complex objects.

 That said, could it be a humble feature request down the road to have
 implicit __deepcopy__ implemented in the instrumented SQLA code  
 injected
 into objects such that it provides this capability. and something
 intuitive to exercise it like.

 copiedobjectinnewsession = session.migrate(currentobject)

 This could require some interface support on the objects if need be.

 Since SQLA is already capable of managing the object graph and state  
 it
 would seem logical to re-use those mechanics to implement this?

 Or am I one foot off my rocker?

It's a use case that comes up now and then, so I'd implement it as a  
SQLA extension and it would perhaps call into the attributes API  
directly to set the appropriate instance state for the new copies.
It would likely be a mixin that implements __deepcopy__().


--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] SQLAlchemy 0.5.1 Released

[Michael Bayer]

This release includes a bunch of architectural enhancements that  
didn't make it into 0.5.0, a handful of bug fixes, and one bigger bug  
fix for a potential memory leak in Query.   Upgrading is not mandatory  
but is recommended.

Changes of note include:

   - the memory leak bug is specifically if you said something like s  
= select([...]); query.join((s, Foo.bar)).  The select() construct was  
being placed into a cache from which it would never be cleared.   The  
caching mechanism within the join logic has been removed as it didn't  
seem to have much performance benefit.  If people notice their  
applications have become slower compared to 0.5.0, please let me know   
- I wasn't able to observe any degradation in performance.
   - we've finally deprecated the Session methods clear()/save()/ 
update()/save_or_update() so those will raise deprecation warnings now.
   - the behavior of concrete inheritance in particular has been  
enhanced, while this is a less common use case people who are using  
this feature should let me know how the new code works out.
   - Declarative includes much nicer support for single-table  
inheritance.  Table columns can be specified on subclasses where they  
will be added to the parent class' table, but only mapped on the  
subclass.   You can do this with classical mapper usage too but it  
usually requires explicit usage of exclude_properties to keep columns  
local to the class they are relevant towards - the declarative  
approach takes care of it for you.
   - the internal approach to triggering mapper compilation has been  
simplified.   the only noticeable effect here should be that you can  
create expressions from class bound attributes without mapper  
compilation occuring, which should help significantly with declarative  
(i.e. when you say primaryjoin=id==OtherClass.someid, no mapper  
compile will be triggered).

Download SQLAlchemy 0.5.1 at:  http://www.sqlalchemy.org/download.html

0.5.1


- orm
 - Removed an internal join cache which could potentially leak
   memory when issuing query.join() repeatedly to ad-hoc
   selectables.

 - The clear(), save(), update(), save_or_update()
   Session methods have been deprecated, replaced by
   expunge_all() and add().  expunge_all() has also
   been added to ScopedSession.

 - Modernized the no mapped table exception and added a more
   explicit __table__/__tablename__ exception to declarative.

 - Concrete inheriting mappers now instrument attributes which
   are inherited from the superclass, but are not defined for
   the concrete mapper itself, with an InstrumentedAttribute that
   issues a descriptive error when accessed. [ticket:1237]

 - Added a new `relation()` keyword `back_populates`. This
   allows configuation of backreferences using explicit
   relations. [ticket:781] This is required when creating
   bidirectional relations between a hierarchy of concrete
   mappers and another class. [ticket:1237]

 - Test coverage added for `relation()` objects specified on
   concrete mappers. [ticket:1237]

 - Query.from_self() as well as query.subquery() both disable
   the rendering of eager joins inside the subquery produced.
   The disable all eager joins feature is available publically
   via a new query.enable_eagerloads() generative. [ticket:1276]

 - Added a rudimental series of set operations to Query that
   receive Query objects as arguments, including union(),
   union_all(), intersect(), except_(), insertsect_all(),
   except_all().  See the API documentation for
   Query.union() for examples.

 - Fixed bug that prevented Query.join() and eagerloads from
   attaching to a query that selected from a union or aliased union.

 - A short documentation example added for bidirectional
   relations specified on concrete mappers. [ticket:1237]

 - Mappers now instrument class attributes upon construction
   with the final InstrumentedAttribute object which remains
   persistent. The `_CompileOnAttr`/`__getattribute__()`
   methodology has been removed. The net effect is that
   Column-based mapped class attributes can now be used fully
   at the class level without invoking a mapper compilation
   operation, greatly simplifying typical usage patterns
   within declarative. [ticket:1269]

 - ColumnProperty (and front-end helpers such as ``deferred``) no
   longer ignores unknown **keyword arguments.

 - Fixed a bug with the unitofwork's row switch mechanism,
   i.e. the conversion of INSERT/DELETE into an UPDATE, when
   combined with joined-table inheritance and an object
   which contained no defined values for the child table where
   an UPDATE with no SET clause would be rendered.

 - Using delete-orphan on a many-to-many relation is deprecated.
   This produces misleading or erroneous results 

[sqlalchemy] Conflict between SQLAlchemy = 0.4.4 and coverage.py?

[James]

I'm using SA underneath a TurboGears 1.0 app. Upgrading SA from 0.4.3
to 0.4.4 causes previously passing unit tests to fail when run in
conjunction with nose's coverage plugin -- I've included an example
stack trace below.

The unit tests run just fine when not using nose's --with-coverage
option.

The only other useful information I have is that some basic logging
shows that more of my model code is being run under 0.4.4 than under
0.4.3, when using coverage.

I don't have a small reproduction, nor have I looked at this in lots
of detail - before I do, is this a known issue, or does it can anyone
suggest a good place for me to start debugging?

Thanks!
James

Stacktrace:

Traceback (most recent call last):
  File /Users/james/virtual/queue/src/pull_client/tests/
test_core_agent.py, line 29, in setUp
self.search_server = model.SearchServer('test_internal',
'test_external', 'test_directory')
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/attributes.py, line 1226,
in init
extra_init(class_, oldinit, instance, args, kwargs)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/mapper.py, line 733, in
extra_init
self.compile()
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/mapper.py, line 237, in
compile
mapper.__initialize_properties()
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/mapper.py, line 257, in
__initialize_properties
prop.init(key, self)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/interfaces.py, line 370, in
init
self.do_init()
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/properties.py, line 181, in
do_init
sessionlib.register_attribute(class_, self.key, uselist=False,
proxy_property=self.instrument, useobject=False,
comparator=comparator)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/unitofwork.py, line 85, in
register_attribute
return attributes.register_attribute(class_, key, *args, **kwargs)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/attributes.py, line 1291,
in register_attribute
inst = proxy_type(key, proxy_property, comparator)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/attributes.py, line 123, in
__init__
self.descriptor = self.user_prop = descriptor
AttributeError: can't set attribute
--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---

[sqlalchemy] Re: Conflict between SQLAlchemy = 0.4.4 and coverage.py?

[Michael Bayer]

this is a known Python issue fixed in 2.6.  See 
http://www.sqlalchemy.org/trac/ticket/1138 
  for details.


On Jan 17, 2009, at 9:23 PM, James wrote:


 I'm using SA underneath a TurboGears 1.0 app. Upgrading SA from 0.4.3
 to 0.4.4 causes previously passing unit tests to fail when run in
 conjunction with nose's coverage plugin -- I've included an example
 stack trace below.

 The unit tests run just fine when not using nose's --with-coverage
 option.

 The only other useful information I have is that some basic logging
 shows that more of my model code is being run under 0.4.4 than under
 0.4.3, when using coverage.

 I don't have a small reproduction, nor have I looked at this in lots
 of detail - before I do, is this a known issue, or does it can anyone
 suggest a good place for me to start debugging?

 Thanks!
 James

 Stacktrace:

 Traceback (most recent call last):
  File /Users/james/virtual/queue/src/pull_client/tests/
 test_core_agent.py, line 29, in setUp
self.search_server = model.SearchServer('test_internal',
 'test_external', 'test_directory')
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
 SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/attributes.py, line 1226,
 in init
extra_init(class_, oldinit, instance, args, kwargs)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
 SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/mapper.py, line 733, in
 extra_init
self.compile()
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
 SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/mapper.py, line 237, in
 compile
mapper.__initialize_properties()
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
 SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/mapper.py, line 257, in
 __initialize_properties
prop.init(key, self)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
 SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/interfaces.py, line 370, in
 init
self.do_init()
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
 SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/properties.py, line 181, in
 do_init
sessionlib.register_attribute(class_, self.key, uselist=False,
 proxy_property=self.instrument, useobject=False,
 comparator=comparator)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
 SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/unitofwork.py, line 85, in
 register_attribute
return attributes.register_attribute(class_, key, *args, **kwargs)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
 SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/attributes.py, line 1291,
 in register_attribute
inst = proxy_type(key, proxy_property, comparator)
  File /Users/james/virtual/queue/lib/python2.5/site-packages/
 SQLAlchemy-0.4.4-py2.5.egg/sqlalchemy/orm/attributes.py, line 123, in
 __init__
self.descriptor = self.user_prop = descriptor
 AttributeError: can't set attribute
 


--~--~-~--~~~---~--~~
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 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---