On Nov 5, 8:47 am, "Ian Bambury" <[EMAIL PROTECTED]> wrote:
> > > If the last rental was yesterday, how does that help me work out if it
> > was
> > > rented in 2007? Or October to October.
>
> > Keep two dates, or run the query two days ago.
>
> That doesn't make sense - two dates don't help,
The problem seems to change every time I provide a solution.
Originally:
> If you
> wanted to find out how many DVDs were never rented from a video rental
> service over the last year, you'd have more than 1000 titles and even if you
> didn't, you'd have to try to match them all up with all the rentals one at a
> time.
This problem can be addressed with a SINGLE last rental date/time.
You can ask for all dvds whose last rental was more than a year ago.
GAE supports inequality queries and order by on dates. You get them
in batches of 1000, but that's not hard to deal with. (The query does
have to account for where it is in the sequence, but the date is a
convenient way to do that.)
Then you wrote:
> > > If the last rental was yesterday, how does that help me work out if it
> > was
> > > rented in 2007? Or October to October.
If the last rental was yesterday, the last rental wasn't in 2007.
Rather than dismiss the question as nonsensical, I error-corrected it
to "previous rental more than a year ago" or "gap between rentals is
bigger than {interval}". Both can be handled by tracking the two most
recent rentals.
On the off chance that you really meant last rental and thought that
the query should return a dvd that was rented yesterday, I pointed out
that querying the single-date record would find that dvd if you ran it
when its last rental really was a year ago.
and expecting someone to
> stay up until midnight on New Year's Eve or miss the chance to produce a
> report or they have missed it for ever isn't really practical, is it?
"a year ago" is defined every day of the year; yes the corresponding
date changes, but .... Similarly, 2007 is defined every day.
Therefore, the relevant queries can be run any time and will return
the correct results. Hold it - is part of "british understatement"
that last-rental is updated on new year's eve for dvds that weren't
rented on new year's eve?
If you only care about a few of the last rentals, it might be
appropriate to use different fields for "last rental", "penultimate
rental", etc. For a larger number, a listproperty with dates might be
appropriate. (You don't want to keep too many because of the
exploding index problem.) In both cases, your code may need to throw
out the oldest date when a new rental occurs. (You might want to keep
"first rental and the number of rentals.) For an indefinite n (all
rentals), you can use the list and a separate table for the "too old
for the list" dates. With that second table, you might have to do
some post-query processing, but you may not need it for many queries.
And, it might be appropriate to periodically query the datastore and
precompute some useful things into other tables, just as one might do
with an SQL db. (The App Engine folks have repeatedly hinted that
background processing is coming soon.)
> Whereas under some circumstances, GAE cannot run the query at all it seems
We've yet to see that.
One thing that GAE doesn't do is allow overlappped datastore
operations.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---
