jwsacksteder@... wrote, at 17.02.2004 19:33:
>>>Note that from the standpoint of the cust_account object, these are all
>>if the relations are strict one-to-one, then why data is divided into
> 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:
def __new__(cls, name, bases, cdict):
cdict["buyer"] = ForeignKey("buyer")
return super(MetaAccount, cls).__new__(cls, name,
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()
__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
>>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.