OK, the example you showed me was strictly "Pager(<select statement>)", so
it was not clear to me that you would have a mapper/class directly
available (code trumps email subject lines).

Anyway, I would advise:

a. looking at Ben Bangert's pager object, since he already asked me all
these questions and came up with something, its probably somewhere on
http://www.pylonshq.com/

b. Im familiar with SQLObject's "generator" thing, and its something that
I may add at some later time, though its interesting nobody has submitted
a ticket to add that functionality.

c. SQLObject's "generator" thing is not very hard to duplicate with SA by
just making your own wrapper function/class around mapper, something like
(i havent really thought about this much but hopefully you get the idea):

def query(criterion):
   class MyThing(object):
      def __getitem__(x):
           if isinstance(x, slice):
              (limit, offset) = # figure out params from the slice object
              return mapper.select(criterion, limit=limit, offset=offset)
           else:
              # get all results and just return
   return MyThing()

as always, if someone submits some fully working code like the above that
can attach directly to Mapper, works efficiently and doesnt break any unit
tests (and hopefully adds a few), it goes straight into the trunk and the
next release !



Qvx 3000 wrote:
> On 3/23/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
>> so you only have a Select, you dont
>> have the Class or Mapper?
>> does that mean you want to inspect
>> the Select to see what Table it refers to,
>> figure out what Mapper talks to that Table ?
>> youre free to do anything like that, you can
>> pull out the "where" clause from the select
>> and send it to the mapper, etc.
>
> I have Class and Mapper. I *want* to use Class or Mapper.
> Even subject says: "deferring mapper selects". The thing
> is that it executes and fetches immediately.
>
> The reason I mentioned Select in my examples was because
> that was the only thing that I could make work in stages.
> I also thought that some kind of "select" could be returned
> by Class - something that can be used to postpone
> execute/fetch and to modify query.
>
> Never mind. In my program I'm already using Class to
> select based on pager.limit and pager.offset. I wanted
> to make it the other way because it is a better way.
> It would make it possible to perform pagination later
> without my business objectes ever needing to clutter
> thair interface with pagination. Things would also be
> efficient because only 10 rows would be fetched at any
> time.
>
> Incidentally, that is the way I saw other people doing
> with SQLObject. SQLObject returns some kind of proxy
> which fetches only when you acces the result. This
> "access" can be slice operation which is than used
> to perform LIMIT/OFFSET modification of underlying query.
> Very Powerful:
>
> results = SOCampaign.select(...)
> campaigns = results[a:b] # Now it performs LIMIT-ed execute/fetch
>
>> although, I am not sure about that design ?
>> if youre dealing with objects you should be
>> passing around the class and a set of criterion,
>> not a raw Select object, no ?
>
> I almost agree. I also want to use Classes and stuff,
> but I don't want to expose my where conditions inside
> controller or event worse - use LIMIT inside my business
> objects (I also have to COUNT inside business objects).
> I just want to be able to say:
>
> # don't want to care about complex WHERE at this point
> leads = campaign_obj.best_leads(min_weight=min_weight)
>
> # and while displaying my "Best Leads" page use...
> pleads = Pager(leads, 'leads') # ... to get only 10 that need to be
> displayed
>
> Currently I must do this:
>
> nav = navigation.Nav(navtxt)
> leads, nav.total = campaign_obj.best_leads(min_weight=min_weight,
> **nav.limit_offset)
>
> and I hate it. All my business functions are constantly
> COUNTing and littering their interface with LIMIT/OFFSET
> noise.
>
>> not sure if this is interesting, but you can
>> also create the unexecuted Select object from
>> the mapper:
>>
>>    s = mapper._compile(Campaign.c.id==7)
>>
>> if you look at what _compile does, youd see why
>> its a risky endeavor to use it if the mapper has
>> any kind of eager loading, esp. with limits and
>> offsets.
>
> I guess that I'm not gonna use it then.
>
> I could make something like this:
>
> class ResultProxy(object):
>     def __init__(self, obj):
>         self._obj = obj
>         self._executed = False
>         self._results = []
>     def _check(self, key=None):
>         if not self._executed:
>             if isinstance(key, slice):
>                 # fiddle with limit and offset
>                 self._obj._kw['limit'] = ....
>             self._results = self._obj.select(*self._obj._arg,
> **self._obj._kw)
>             self._executed = True
>     def __getitem__(self, key)
>         self._check(key)
>         if isinstance(key, slice):
>             return self._results
>         else:
>             return self._results[key]
>     def __len__(self):
>         self._check()
>         return len(self._results)
>     def __...__(self):
>         self._check()
>         return ...
>
> class PagerSupport(object):
>     def pselect(self, *arg, **kw):
>         self._arg = arg
>         self._kw = kw
>         return ResultProxy(self)
>
> class SACampaign(PagerSupport):
>     pass
>
> This is something I wrote inside this mail so it
> is obviously untested and with many bugs and
> wrong design decisions, but it is here just to
> give you a general idea.
>
> The thing is that I *don't* like it:
> - I have to subclass
> - I have to use special "pselect" functions
> - I have to write ResultProxy class
> - I have to use SA results in nonobvious way
>   (it may be obvious for SO but not for SA)
> - I cannot give Pager to others because it
>   is too coupled
>
> It would be better if it was part of the framework.
> It seems almost there because you can do it
> with Select. Or should I say: I guess you can
> do it. I didn't understand if it would work or not
> when you mentioned eager loading...
>
> Regards,
> Tvrtko
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> _______________________________________________
> Sqlalchemy-users mailing list
> Sqlalchemy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users

Reply via email to