Re: [SQLObject] proxy attributes

[alexander s. <al...@an...>]

jws...@ra... wrote, at 17.02.2004 19:33:

>>>Note that from the standpoint of the cust_account object, these are all
>>>one-to-one relations.
> 
>>if the relations are strict one-to-one, then why data is divided into 
>>separate tables?
> 
> They are actually many-to-one, but from this side of the join it looks like
> a one-to-one. This customer account has that one buyer. From the buyer side
> of the join, that one buyer has many potential customer accounts.

well, this is a sketch of how we did attribute delegation before 
switching to Daniel's patch:

     class Buyer(SQLObject):
         whatever =Col()

     class MetaAccount(MetaSQLObject):
         def __new__(cls, name, bases, cdict):
             cdict["buyer"] = ForeignKey("buyer")
             return super(MetaAccount, cls).__new__(cls, name,
                 bases, cdict)

         def __init__(cls, name, bases, cdict):
             cls._buyer_attrs = ["whatever"]
             super(MetaAccount, cls).__init__(name, bases, cdict)
             for _attr in cls._buyer_attrs:
                 def _get(self, attr=_attr):
                     return getattr(self.buyer, attr)
                 def _set(self, value, attr=_attr):
                     setattr(self.buyer, attr, value)
                 setattr(cls, _attr, property(_get, _set))
             cls._reprItems = lambda s: s.buyer._reprItems() \
                 + super(s.__class__, s)._reprItems()

     class Account(SQLObject):
         __metaclass__ = MetaAccount

... and if you want Account.new() to update (or create) the buyer, you 
need some more magic to tweak classmethod `new` as well.

please note that this code is stripped down as much as possible and is 
not tested, but you can get the idea.

however, there were some problems with this delegation, discovered by 
Oleg Broytmann: as far as i understand, account.whatever cannot be 
accessed unless at least one instance of Buyer is created.  see 
http://sourceforge.net/mailarchive/forum.php?thread_id=3879735&forum_id=30269

>>perhaps relationships may be optional, e.g. some customers are buyers, 
>>and others are not?  if this is the case, then you may consider using 
>>SQLObject inheritance patch by Daniel Savard.
> 
> No, customers = accounts and buyers = people. Inheritance is one way of 
> looking at it, though. I will investigate that.

perhaps not.  (i do not think that you mean "account is a man" 
inheritance, do you?)  in our application, we had an object-oriented 
information model, class inheritance was there from the outset.

best wishes,
alex.