Thread: [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 02:25:17
Attachments:
multiplejoinreturn.diff
|
Hi guys 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 ;) thanks for attention and for any help... -- Michel Thadeu Sabchuk Curitiba - Brasil |
From: Oleg B. <ph...@ph...> - 2005-03-10 10:33:56
|
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. |
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 |
From: Oleg B. <ph...@ph...> - 2005-03-10 16:32:37
|
On Thu, Mar 10, 2005 at 07:59:36AM -0300, michelts wrote: > 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? Cannot think of any good name... MultipleJoinIndirect? > I didn't find a way to know the table style, Table.sqlmeta.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)... Aha, I see now! And still you can run a "for" loop over it. Very nice indeed! > Sorry the broken patch :), I'm not so familiar with sqlobject source, > I must give it more time, today I will have this time ;) Please consider also writing a few tests for your patch. > sorry my bad english... Not worse than mine. :) Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: michelts <mic...@gm...> - 2005-03-13 18:56:00
Attachments:
sqlmultiplejoin.diff
|
Hi again Oleg and all! I attach a patch, the patch contains a subclass of MultipleJoin, I call SQLMultipleJoin, it is not complete at all I think, I need to write the test yet, I'm quite busy in this 2 weeks (university tests :)... I make a subclass and I agree to have a subclass working as that, but I think a SelectResult should be the default return value for the join. I can convert the result to a list, but I can't convert a list to a select result and this way the join will work more like a select statement (like Table.select()). What do you think? seeya On Thu, 10 Mar 2005 15:31:55 +0300, Oleg Broytmann <ph...@ph...> wrote: > On Thu, Mar 10, 2005 at 07:59:36AM -0300, michelts wrote: > > 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? > > Cannot think of any good name... MultipleJoinIndirect? > > > I didn't find a way to know the table style, > > Table.sqlmeta.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)... > > Aha, I see now! And still you can run a "for" loop over it. Very nice > indeed! > > > Sorry the broken patch :), I'm not so familiar with sqlobject source, > > I must give it more time, today I will have this time ;) > > Please consider also writing a few tests for your patch. > > > sorry my bad english... > > Not worse than mine. :) > > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ ph...@ph... > Programmers don't die, they just GOSUB without RETURN. > -- Michel Thadeu Sabchuk Curitiba - Brasil |
From: Oleg B. <ph...@ph...> - 2005-03-14 11:03:25
|
On Sun, Mar 13, 2005 at 03:54:48PM -0300, michelts wrote: > I attach a patch, the patch contains a subclass of MultipleJoin, I Looks good. Can you make a few simple tests for it? A test for isinstance(), a test for accumulate functions or such... > call SQLMultipleJoin, it is not complete at all I think, What is not complete? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: michelts <mic...@gm...> - 2005-03-14 19:28:30
|
Hi! On Mon, 14 Mar 2005 14:03:12 +0300, Oleg Broytmann <ph...@ph...> wrote: > On Sun, Mar 13, 2005 at 03:54:48PM -0300, michelts wrote: > > I attach a patch, the patch contains a subclass of MultipleJoin, I > > Looks good. Can you make a few simple tests for it? A test for > isinstance(), a test for accumulate functions or such... I can and I will :) > > call SQLMultipleJoin, it is not complete at all I think, > > What is not complete? The tests ;) thanks... > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ ph...@ph... > Programmers don't die, they just GOSUB without RETURN. > -- Michel Thadeu Sabchuk Curitiba - Brasil |