[Carlos Ribeiro <carribeiro@gm...>]

On Thu, 20 Jan 2005 15:13:10 -0600, Ian Bicking <ianb@...> wrote:
> Carlos Ribeiro wrote:
> > When I need compound keys, I usually end up resorting to the
> > selectBy() method. Couldn't it be optimized a little bit? A composite
> > key method could be 'registered' in the class declaration, hinting at
> > the need for extra indexes for that columns. The example below may
> > seem a little bit forced, but it shows the basic idea:
> >
> > class Person(SQLObject):
> >     firstName = StrCol()
> >     lastName = StrCol()
> >     byName = CompositeKey('firstName', 'lastName')
> >
> > The CompositeKey function would return a method, searching for the
> > firstName & lastName. The appropriate indexes can also be created
> > automatically. Is it a workable solution?
> 
> I assume you have compound keys in addition to a single primary key,
> otherwise you couldn't get as far as selectBy.  They may even be
> mutable, similar to a column marked alternateID=True.  I have an idea in
> mind that would make this fairly easy to implement, without really being
> part of SQLObject, but it requires a fair amount of refactoring.

I guess I'm getting used to SQLObject's automatic ID's. So yes, a
table still has the standard primary key; the composite key is an
alternate key. My idea was roughly to declare the components of the
composite key as individual columns, and then to declare the composite
key in such a way that SQLObject could automatically add the
by<CompositeKey> method and any necessary index.

> One of the reasons I brought up inheritance is that I wanted to resolve
> this before making those changes, so that Oleg doesn't have to merge
> these rather large changes.
> 
> In this case, I want MetaSQLObject to look for objects that have a
> __add_to_class__ method (or something like that -- I'm just making that
> name up).  Then that method would be called with the class and attribute
> name as arguments, and if there was a return value that would be used in
> place of the original object.  Col (and subclasses) would be one case of
> this -- basically they'd look like:
> 
> class Col(object):
> 
>      def __add_to_class__(self, soClass, attrName):
>          soClass.addColumn(attrName, self)
> 
> Your CompositeKey would look like:
> 
> class CompositeKey(object):
> 
>      def __init__(self, *colNames):
>          self.colNames = colNames
> 
>      def __add_to_class__(self, soClass, attrName):
>          return CompositeGetter(soClass, colNames)
> 
> class CompositeGetter(object):
> 
>      def __init__(self, soClass, colNames):
>          self.soClass = soClass
>          self.colNames = colNames
> 
>      def __call__(self, *values):
>          assert len(values) == len(self.colNames)
>          args = dict(zip(self.colNames, values))
>          result = list(self.soClass.selectBy(**args))
>          assert len(result) == 1
>          return result
> 
> CompositeKey.__add_to_class__ could also add an index to soClass if you
> wanted it to.  Joins would generally be implemented in a similar way.
> You could also use descriptors (property or your own custom descriptor)
> to add attributes.

The standard getter & setter for a CompositeKey could possibly take a
tuple as an argument, and then set each composnent column accordingly.

> I think the result will make MetaSQLObject easier to understand, and
> make it easier to add extensions like these.

Agreed.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro@...
mail: carribeiro@...