Scott Sanders wrote:
> Can I get a yes/no on this? I would like this to be a integral part of
> SQLObject. Even the ability to have multiple factories.
Sorry, I think it was one of those I-need-to-think-about-this emails
that I put off and then forgot about it. Feel free to pester if I miss
things.
> On Oct 29, 2004, at 11:17 AM, Scott Sanders wrote:
>
>> Ian,
>>
>> I have successfully been using SQLObject svn trunk for a few days now,
>> without modifications. I have implemented automatic class generation
>> by reading information from the database about classes and their
>> columns and joins. I did this by extending MetaSQLObject with my own
>> behavior, and a factory method called getClass(classname), which
>> checks the registry, and then constructs a new class if the registry
>> does not contain the proper class.
This sounds very similar to ezSqlObject, except it uses __getattr__ to
create the classes (e.g., db.User, instead of getClass('user')).
>> The problem I am running into now, is when you have joined classes,
>> the joined classes have to be explicitly loaded. In your users/roles
>> example, my code would have to look something like this:
>> userClass = getClass('user')
>> roleClass = getClass('role') #if this is not called here, user.roles
>> will not be defined, because the role class is not in the registry
>> user = userClass.get(1)
>> print list(user.roles[0])
So you are creating the joins dynamically as well? How does that work?
How lazy do you need the class creation to be?
I notice there's no .tables() method on connections, just .tableExists()
-- it's a pretty no-brainer that such a method should exist, returning a
list of strings. Would that be enough? Then you could create all the
classes at startup.
>> It would great if the registry was allowed to have a factory method
>> set to attempt automatic class creation if the class does not exist.
>> If I coded this up as a patch, would it be accepted?
I'm not entirely clear what you are thinking. Right now the registry
tracks classes, but it never returns classes. Instead class references
are pushed into the places they are needed, using callbacks which are
triggered on class creation. So I'm not sure where this would fit.
--
Ian Bicking / ia...@co... / http://blog.ianbicking.org
|