Michael Bayer wrote:
>
> On Jun 13, 2006, at 4:03 AM, Lele Gaifax wrote:
>
>>
>> Wouldn't something like
>>
>> diary = FunctTable('diary(:iddip,:fromdate,:todate,:live)', ...)
>>
>> be a viable solution to the problem as well as a nicer approach to
>> ticket #172, if at all possible?
>>
>
> yes this is why I put all those notes of "i want to think about this" at
> the bottom of ticket 172. because a Function right now is treated as a
> column-based object, not a "fromclause" type of object. I need to
> consider if it really is just a "fromclause" object which when used in a
> column clause is the same as an embedded select, or if in fact the
> Function needs to implement both interfaces (this would be done via two
> separate objects, not multiple inheritance, however the outside world
> would still just deal with "func").
Well, I think they are two different beasts, that probably deserve a
distinct object each. From my POV, I don't think "function" is a good
name for "selectable stored procedures": they are rather a "parametric
datasets" (ie, multiple columns, multiple rows).
In fact, it's unfortunate SQL does not allow to hide the nature of the
dataset behind say a parametric VIEW. BTW, this particular thingie
confuses most of the software I tried, to the point that I started
considering to refactor the SSP into a more "standard" flow (a
traditional SP that stores it's computed dataset into a temporary table,
maybe keyed by the parameters and some ID of the caller...). Right now I
use that to produce a report, using raw DB-API calls, so that's not a
big deal.
> if the Function is then really a "fromclause" object, what columns does
> it export ? without trying anything, i am leaning towards just "*" as
> the most general answer....but that might also present problems with
> joins etc.
Yes, AFAIK this kind of SP is usable only with the idiom::
SELECT a,b,c FROM sp(:x, :y, :z)
(this both on PG and on Firebird, where I used them *a lot*).
> it may be the case that we have to do something like what youre talking
> about, i.e. a Function that has explicit columns and all. maybe just
> making a totally new object would be better, it would have to include
> information about the parameters and its result columns (this one has
> different types for the parameters and the result columns):
>
> f = Function('diary',
> Parameter('iddip', Integer),
> Parameter('fromdate', Date),
> Parameter('todate', Date),
> Parameter('live', Boolean),
> Column('result_col', String),
> Column('result_date', Date)
> )
>
> f(5,datetime(5,2,2006), datetime(5,5,2006), True).select()
>
> what do you think ? this would actually be a schema object.
That would be great! As I wrote in my previous msg, this is basically a
Table with the ability to accept a bindparams, and your suggestion seems
to fit perfectly. As said above, I'd use a different name for it,
though, as I find "Function" a bit misleading. Isn't ParametricTable a
better choice?
Thank you,
ciao, lele.
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
