|
From: Scott S. <sc...@st...> - 2004-10-29 18:20:41
|
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.
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])
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?
Thanks,
Scott
|
|
From: Scott S. <sc...@st...> - 2004-12-05 17:20:35
|
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.
Thanks
Scott
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.
>
> 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])
>
> 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?
>
> Thanks,
> Scott
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
|
|
From: Oleg B. <ph...@ph...> - 2004-12-05 18:26:55
|
On Sun, Dec 05, 2004 at 09:07:03AM -0800, Scott Sanders wrote:
> >The problem I am running into now, is when you have joined classes,
> >the joined classes have to be explicitly loaded.
I've stumbled over this many times, but I don't have an idea where
you can load the class from, if its not already loaded. You'd like to
provide your own callback ("factory function")? Why not just import
neccessary modules?
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ ph...@ph...
Programmers don't die, they just GOSUB without RETURN.
|
|
From: Scott S. <sc...@st...> - 2004-12-05 18:54:07
|
I cannot just import the classes, because they don't exist. I load
class columns and joins from the database, and then build up a class
for SQLObject to use. It is working great, except that I have to use
my own getClass() method, and have to preload the non-existent classes
before I use them. If the regsitry could call my factory method, all
child classes will automagically be created.
Scott
On Dec 5, 2004, at 10:26 AM, Oleg Broytmann wrote:
> On Sun, Dec 05, 2004 at 09:07:03AM -0800, Scott Sanders wrote:
>>> The problem I am running into now, is when you have joined classes,
>>> the joined classes have to be explicitly loaded.
>
> I've stumbled over this many times, but I don't have an idea where
> you can load the class from, if its not already loaded. You'd like to
> provide your own callback ("factory function")? Why not just import
> neccessary modules?
>
> Oleg.
> --
> Oleg Broytmann http://phd.pp.ru/
> ph...@ph...
> Programmers don't die, they just GOSUB without RETURN.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
|
|
From: Oleg B. <ph...@ma...> - 2004-12-05 19:15:33
|
On Sun, Dec 05, 2004 at 10:54:00AM -0800, Scott Sanders wrote:
> It is working great, except that I have to use
> my own getClass() method
Isn't it exactly the callback you need? Just setup your own registry,
redefine getClass(), and put all of your classes to that registry.
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ ph...@ph...
Programmers don't die, they just GOSUB without RETURN.
|
|
From: Scott S. <sc...@st...> - 2004-12-05 19:21:55
|
OK, then can I just get an addRegisrty() call, since they are by default automatically generated? Either way is completely acceptable to me, as long as I can run SQLObject unmodified. Thanks Scott On Dec 5, 2004, at 11:15 AM, Oleg Broytmann wrote: > On Sun, Dec 05, 2004 at 10:54:00AM -0800, Scott Sanders wrote: >> It is working great, except that I have to use >> my own getClass() method > > Isn't it exactly the callback you need? Just setup your own > registry, > redefine getClass(), and put all of your classes to that registry. > > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ > ph...@ph... > Programmers don't die, they just GOSUB without RETURN. > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss |
|
From: Oleg B. <ph...@ph...> - 2004-12-05 19:37:44
|
On Sun, Dec 05, 2004 at 11:21:41AM -0800, Scott Sanders wrote:
> OK, then can I just get an addRegisrty() call
Every SQLObject has the attribute _registry. What do you want for
addRegistry()?
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ ph...@ph...
Programmers don't die, they just GOSUB without RETURN.
|
|
From: Scott S. <sc...@st...> - 2004-12-05 21:42:49
|
Are you saying I should have a registry outside of the normal registry process? I still want to be able to use all of SQLObjects methods normally. There is nothing wrong with the master registry not knowing about my registry. Something strikes me as wrong here. Scott On Dec 5, 2004, at 11:37 AM, Oleg Broytmann wrote: > On Sun, Dec 05, 2004 at 11:21:41AM -0800, Scott Sanders wrote: >> OK, then can I just get an addRegisrty() call > > Every SQLObject has the attribute _registry. What do you want for > addRegistry()? > > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ > ph...@ph... > Programmers don't die, they just GOSUB without RETURN. > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss |
|
From: Oleg B. <ph...@ma...> - 2004-12-05 21:56:08
|
On Sun, Dec 05, 2004 at 01:42:39PM -0800, Scott Sanders wrote:
> Are you saying I should have a registry outside of the normal registry
> process?
Yes. Something like this:
class MyRegistry(ClassRegistry):
def getClass(self, name):
return SomethingAppropriate
class MyTable(SQLObject):
_registry = MyRegistry()
columns = get_the_list_of_columns_from_the_db("my_table")
joins = get_the_list_of_joins_from_the_db("my_table")
for column in columns:
MyTable.addColumn(column)
for join in joins:
MyTable.addJoin(join)
Do you need anything besides that?
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ ph...@ph...
Programmers don't die, they just GOSUB without RETURN.
|
|
From: Ian B. <ia...@co...> - 2004-12-05 21:20:17
|
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
|
|
From: Scott S. <sc...@st...> - 2004-12-06 18:59:52
|
On Dec 5, 2004, at 1:20 PM, Ian Bicking wrote:
>>>
>>> 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')).
yes, it would be similar.
>
>>> 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?
Yes, I am creating the joins dynamically, which creates the problem
that I don't know which classes are going to join to other non-existent
classes. I don't care about lazy, my only problem is that the python
code that is written will not know which child/grandchild classes will
need to exist.
>
> 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.
If the answer from the SQLObject team is to create them up front, I am
willing to do that. I would just rather not.
>
>>> 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.
The registry always returns a class when asked (for classes in joins,
etc), or am I just smoking something??? I understand it never
generates a class.
Scott
|
|
From: Ian B. <ia...@co...> - 2004-12-06 19:14:20
|
Scott Sanders wrote:
>> 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.
>
>
> The registry always returns a class when asked (for classes in joins,
> etc), or am I just smoking something??? I understand it never
> generates a class.
The registry is meant to deal with circular references, which is why it
doesn't return classes at all. Since if A depends on B, and B depends
on A, the calls will look like:
class A:
my_b = registry.getClass('B') # registry goes off and creates B...
class B:
my_a = registry.getClass('A') # but A doesn't exist yet, and
# it won't until B is finished being created
Instead it works like:
import classregistry
registry = classregistry.registry('default')
class A:
pass
registry.addClassCallback('B', lambda cls: A.my_b = cls)
registry.addClass(A)
# So far the registry hasn't done anything at all
class B:
pass
registry.addClassCallback('A', lambda cls: B.my_a = cls)
# The registry immediately calls that lambda passing in A
registry.addClass(B)
# The registry now calls the previous lambda, passing in B
Maybe it would be helpful if the registry had a method to return the
names of all the classes that are still pending? That would be:
def pendingClasses(self):
return self.callbacks.keys()
After you've loaded a class, you could check if there were any pending
classes, and try to load them up.
--
Ian Bicking / ia...@co... / http://blog.ianbicking.org
|
|
From: Scott S. <sc...@st...> - 2004-12-06 19:47:09
|
On Dec 6, 2004, at 11:10 AM, Ian Bicking wrote: > Maybe it would be helpful if the registry had a method to return the > names of all the classes that are still pending? That would be: > > def pendingClasses(self): > return self.callbacks.keys() > > After you've loaded a class, you could check if there were any pending > classes, and try to load them up. This is essentially all I am trying to do, solve the chicken/egg problem. This would be a fine solution to the problem. Thanks Scott |
|
From: Scott S. <sc...@st...> - 2004-12-27 21:41:42
|
On Dec 6, 2004, at 11:10 AM, Ian Bicking wrote: > Maybe it would be helpful if the registry had a method to return the > names of all the classes that are still pending? That would be: > > def pendingClasses(self): > return self.callbacks.keys() I just implemented this in my own code (registry.callbacks.keys()), and it works great. I would not worry about patching SQLObject at this point, as that pointer was exactly what I needed. Thanks guys, Scott |
