Re: [SQLObject] Return an SResult object from a MultipleJoin
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: michelts <mic...@gm...> - 2005-03-10 10:59:50
|
I think on that and I agree, a subclass will be better than edit the MultipleJoin class, does you have any name suggestion for the class name? But, in other perspective, it is the same multiplejoin anyway... What do you think, for any case is ok. To switch asList at run time will be a usefull feature, but how can I call the join as a function? object=SomeClass.get(1) object.joinedobjects object.getJoinedobjects(...) ? I didn't find a way to know the table style, I will look at the source again and find a way to use the table style... I will explain the usage of this feature for me: I have Servlets (webware) that iterates over the join to show the results, I need to test the length of the list, this way I think it will be better to use join.count() instead of len(join)... I will have access to some functions like sum(), avg(), max(), min()... Sorry the broken patch :), I'm not so familiar with sqlobject source, I must give it more time, today I will have this time ;) thanks for attention and sorry my bad english... On Thu, 10 Mar 2005 13:33:49 +0300, Oleg Broytmann <ph...@ph...> wrote: > Hello! Few thoughts about the patch... > > On Wed, Mar 09, 2005 at 11:25:12PM -0300, michelts wrote: > > I attached a patch to return a result object rather than a simple list > > in a MultipleJoin (I will try the same for the RelatedJoin but it's > > half past eleven pm, I think I won't do a good job :)... > > > > There is no efect over a normal MultipleJoin, I must specify that I > > don't want a list as result: > > > > items=MultipleJoin('Item', asList=True) > > items=MultipleJoin('Item', asList=False) > > > > The default value for asList is True, then there is no change on the > > current behavior, but I can specify myself what I want to receive ;) > > Can I switch asList at run-time? (Currently it's a bit hard - I have > to modify the column's description in the class.) > May be instead of adding a new parameter you can implement it as a > subclass? I am not sure which way is better. It probably depends on use > cases. What are the typical use cases for the feature, in your opinion? > Wouldn't it be betetr to ask the tables for style instead of using > the fixed style "underToMixed"? > > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ ph...@ph... > Programmers don't die, they just GOSUB without RETURN. > -- Michel Thadeu Sabchuk Curitiba - Brasil |