[sqlalchemy] Re: PickleType with custom pickler

2006-12-08 Thread dmiller


On Dec 8, 2006, at 1:30 PM, Michael Bayer wrote:

 the reason that get_history calls attribute_manager.get_history is
 because all awareness of attribute history is handled by the
 attribute module.  the reason attribute_manager then calls the
 InstrumentedAttribute off of the class is because thats where
 AttributeManager reprents the behavior for a specific class attribute.
 ColumnProperty knows nothing about InstrumentedAttribute.

Hmm...I guess ColumnProperty is not really what I'm looking for then-- 
it looks more like a layer between user code and the attribute  
manager. I want to be able to control the communication between the  
attribute manager and the mapped object. Currently AttributeManager  
and friends just access object.__dict__ directly, which means I can't  
get between them...too bad.

I guess what I'm really looking to customize is  
InstrumentedAttribute, which is even more formidable than  
ColumnProperty. Is there an easy way to tell SA to use a custom  
InstrumentedAttribute class?


 if you look at the constructor for InstrumentedAttribute itself, youll
 see it takes two callables which provide the compare function and  
 the
 copy function.  these are provided by the TypeEngine object via the
 ColumnLoader, which is off the ColumnProperty.  So i would propose  
 that
 these two arguments become optional keyword arguments to  
 ColumnProperty
 which ColumnLoader/DeferredLoader pick up on and send to their
 init_class_attribute method, so that you can send in whatever compare
 and copy callables you want.

I'm not sure if that would actually solve my problem since compare  
and copy do not allow me to mutate the data as it passes from SA to  
the object. Could we create a mapper extension point that would get  
called to check if an object is modified? It would need be hooked  
into the logic inside locate_dirty(). That would allow me to do this  
whole thing with a mapper extension.

~ Daniel

--~--~-~--~~~---~--~~
 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] A better CascadeOptions impl

2006-11-15 Thread dmiller

Here's a better CascadeOptions implementation:

from sets import Set
class CascadeOptions(Set):
 keeps track of the options sent to relation().cascade
 def __init__(self, arg=):
 values = util.Set([c.strip() for c in arg.split(',')])
 if delete-orphan in values: self.add(delete-orphan)
 if delete in values or self.delete_orphan or all in  
values: self.add(delete)
 if save-update in values or all in values: self.add 
(save-update)
 if merge in values or all in values: self.add(merge)
 if expunge in values or all in values: self.add(expunge)
 for name in (delete-orphan, delete, save-update,  
merge, expunge):
 setattr(self, name.replace(-, _), name in self)
 # refresh_expire not really implemented as of yet
 #self.refresh_expire = refresh-expire in values or all  
in values
#def __contains__(self, item):
#return getattr(self, item.replace(-, _), False)

This does the item.replace(-, _) part once on initialization  
rather than every time __contains__ is called. It works as long as  
nothing ever tries to change the options after the object is  
initialized.

~ Daniel

--~--~-~--~~~---~--~~
 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: Constructing where-clauses dynamically

2006-11-06 Thread dmiller


On Nov 6, 2006, at 3:31 PM, Randall Smith wrote:


 dmiller wrote:
 Is there a reason why this doesn't work:

...

 order = session.query(Order).get(1) # assume order exists
 itemsNotInOrder = session.query(Item).select(Item.c.order != order) #
 ERROR!

 This should work.
 itemsNotInOrder = session.query(Item).select(Item.c.order_id !=  
 order.id)

Thanks for the response Randall. I know that works...read on below.




 The Item.c object does not have an 'order' attribute. Is there a
 reason why it can't have one?

 I would guess that attributes of Item.c are Column instances, which
 order is not.  Your approach seems intuitive (I did the same thing
 once), but the above example I think is easy enough.

 I could be wrong or missing something.  Just trying to be helpful.

What I'm getting at is that SA has all the necessary details to  
create the WHERE clause automatically (it already does something very  
similar when constructing joins). My case is a simple case with a  
single-column foreign key (it's even a pretty stupid case at that :).  
However, it demonstrates a powerful query construction concept that  
seems to be lacking from SA. Ideally it should also work with a multi- 
column foreign key, which is much more tedious to do manually (as you  
suggested) because it requires a separate condition for each column  
in the key. It seams like this would be fairly simple to add, maybe  
I'll give it a try if I can find the time.

~ Daniel

--~--~-~--~~~---~--~~
 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
-~--~~~~--~~--~--~---