Re: Interaction of annotate() and values()
On Tue, Feb 10, 2009 at 1:53 PM, Malcolm Tredinnick
wrote:
>
> On Sun, 2009-02-08 at 15:56 +0900, Russell Keith-Magee wrote:
> [...]
>> There is a slight complication, though. The ordering of values() and
>> annotate() is significant - values() controls the grouping of
>> annotated values if it precedes the annotate().
>
> This is the nub of the problem, isn't it. We possibly messed up here by
> overloading what values() does/means. :-(
I'm not convinced we messed up - it's a messy situation in general.
The behaviour as implemented is mostly a requirement of the way
values() is interpreted. Once you start reducing the set of columns
that is returned by a queryset, you pretty much have to start
interpreting that as a grouping. The only other option I can think of
is to require that once a queryset contains an aggregate, you continue
to retrieve all the columns, but you only get back the set you
requested, thereby losing all the optimization benefits of values().
If you can propose a better interpretation for values() in these
circumstances, it probably isn't too late to do something about it,
but time is running out fast.
> Problem is, adding a new API to specify the grouping order has the same
> drawbacks as having to write values() twice -- you end up needing to
> name the fields once for values() and once for the order they group by
> and then you think about maybe extracting the latter info from the
> former and we're back where we started.
You also inherit all the validation problems of needing to ensure that
all the values() columns are also mentioned in the group_by(). It
could be munged into some interpretation of "working", but it wouldn't
be pretty as an end user API.
>> However, you can't
>> mention the annotated column in a values() clause before it is
>> specified, so are left in a situation where you can't actually return
>> the annotated value. For example in the query:
>>
>> >>> Book.values('title','isbn').annotate(n_authors=Count('authors'))
>>
>> n_authors wouldn't be returned in the result set, and there isn't any
>> way to add it to the returned values.
>>
>> So - some options:
>>
>> 1) Leave things as-is. Annotated columns always appear in the result
>> set. This is inconsistent with extra(), and means you can't use
>> annotated queries in __in clauses.
>
> Unintuitive and inconsistent. As much as I'm willing to declare extra()
> the odd man out for most API consistency arguments and as an example of
> solid behaviour, I like the current behaviour with
> extra(...).values(...).
Just to clarify - what exactly do you see as the current expected
behaviour of extra(select=).values(...)? I started fiddling with this
last night in the context of ticket #10132, but it doesn't appear (as
far as I can tell) to be specifically documented. When I started
messing about with code, I was somewhat surprised that I didn't get
flooded with test failures.
By way of example, this is what 1.0.X produces:
>>> Book.objects.extra(select={'a':'name','b':'price','c':'pages'}).values('name','pages','a')
[{'a': u'Book 1', 'c': 11, 'b': Decimal("11.11"), 'name': u'Book 1',
'pages': 11}, ...
>>> Book.objects.extra(select={'a':'name','b':'price','c':'pages'}).values('name','pages')
[{'name': u'Book 1', 'pages': 11}, ...
I couldn't find a test case that covers this usage - every use of
extra() that I found intersecting with named values() specifically
included all the extra selected columns in the values() clause. The
behaviour as implemented seems to walk a weird middle ground between
including all extra columns, and only including extra columns if
specifically requested.
To my mind, the second answer is right, but the first result should be:
[{'a': u'Book 1', 'name': u'Book 1', 'pages': 11}, ...
Have I missed something obvious here?
>> 2) Modify things slightly - annotate() calls before a values() call
>> aren't automatically added to the results, but annotate() calls after
>> values() are included automatically. This would allow annotations to
>> always be returned, optionally under those circumstances that allow
>> (i.e., annotate() before values()).
>
> This is probably the least intrusive and most supportable option.
This is pretty much the conclusion I had come to - I just didn't want
to sway anyone else's decision making process.
>> 3) Rely on multiple calls to values() to get annotate columns into the
>> result set. i.e., the previous example would need to become something
>> like:
>>
>> >>> Book.values('title','isbn').annotate(n_authors=Count('authors')).values('title','isbn','n_authors')
>>
>> This has the potential to be a bit fragile - we would need to put in
>> all sorts of checks for changes in column lists between successive
>> calls to values() - but it would allow all combinations of annotation.
>
> No, really... you were just throwing this out to see how it sounded when
> it the wall and broke, right?
Pretty much :-)
> Not a good option.
Completely agreed.
Russ %-)
--~--~---
Django, initial data and custom SQL
Hello, I would like to suggest (patch will follow if someone concurs) that custom sql is executed after Django has created indexes. Django is (in my opinion) a bit optimistic regarding index creation, and by looking at pg_stat_* output I see that at least a couple of indexes on busy tables hasn't been used - ever. The obvious thing to do is to drop these. Next step would be to sync this with my test and staging environment so I can run tests against my data/application and verify that something hasn't broken - and here's basically where it gets interesting. Since Django executes my custom SQL before creating indexes, it's impossible to achieve something that hooks into initdb/syncdb. I know that it is "good custom" to create indexes after inserting data – but fixtures in Django is already executed after creating indexes, so that can't be the reason.. So, without further ado, what I would like to know is if there's a reason to why custom SQL is executed before index creation. Kind regards, Johan bergström --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine port
Malcolm, Russell, James, Thanks for taking the time to respond so thoroughly to my questions. I think that these questions are rooted in the unrealistic idea that something that looks like it would be good relationship- or PR-wise is also a good development priority. As I expressed, I've simply thought that GAE would be a no-brainer, but that is obviously not the case when viewed against other development work with more concrete demand. Now it is time for me to put-up or shut-up. Hopefully it will not be the latter (and making a post like this can be a good motivator)! -Dave On Mon, Feb 9, 2009 at 11:20 PM, Malcolm Tredinnick wrote: > > On Fri, 2009-02-06 at 09:51 -0500, David Stenglein wrote: >> I have to ask a question here. Why is there such reticence regarding >> App Engine? It would >> seem to me that App Engine has been a feather in the cap for Django. A >> lot of people don't know Django and at a previous job, I was able to >> say that "Google chose django" for App Engine to help validate my use >> of it. > > To echo everybody else; There simply isn't any reticence. > >> >> If so, why the seeming lack of excitement around App Engine? Are >> google engineers not involved in the community? > > Possibly. If they are, they aren't posting from their @google.com > addresses, as far as I can see on this list. > > I would point out that the original GAE integration with Django could > have been implemented quite differently and a lot of this could have > Just Worked out of the box. However, there were reasonably (not > perfectly) valid corporate and legal reasons why Google chose not to > and/or couldn't do that. So the thing works both ways. Google made some > choices and this thread is now about working around those choices to > integrate more nicely. > > Regards, > Malcolm > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine port
On Feb 10, 4:25 am, Malcolm Tredinnick wrote: > I have a reasonably fleshed out plan to make things easier here in the > Django 1.2 timeframe. That's good to know. I see there's already a hook for a custom query class which would work well as far as querying is concerned, but doesn't seem to be so useful for inserting, updating and deleting, and date and count queries. That's because these are implemented as subclasses of Query, and although we can substitute our own Query subclass for Query, as is done in the Oracle backend, what we actually need is to be able to also affect the behaviour of the subclasses. If one wanted e.g. some special syntax for an INSERT query, how would one hook into the machinery to deliver custom SQL for insertions? Regards, Vinay Sajip --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine port
Le 10 févr. 09 à 05:25, Malcolm Tredinnick a écrit : > There's also > simple enough stuff like removing the last vestiges of raw SQL from a > couple of places (most notable related fields, but that should > probably > go after, or in tandem with, a rewrite of related fields to clean them > up in general). That's the goal of #10109. Good to know there is eventually an interest in this. Regards, David http://code.djangoproject.com/ticket/10109 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django, initial data and custom SQL
On Feb 10, 1:13 pm, Johan Bergström wrote: > Since Django executes my custom SQL before creating indexes, it's > impossible to achieve something that hooks into initdb/syncdb. I know > that it is "good custom" to create indexes after inserting data – but > fixtures in Django is already executed after creating indexes, so that > can't be the reason.. So, without further ado, what I would like to > know is if there's a reason to why custom SQL is executed before index > creation. Isn't this doable with initial SQL? http://docs.djangoproject.com/en/dev/howto/initial-data/#initial-sql Testing here with SQLite, it'd seem it runs the custom SQL at the very last point, so you could actually add some ALTER TABLE statements, I guess. Again, this is testing with SQLite, and SQLite doesn't do indexing. Maybe I misunderstood? - Ludvig --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django, initial data and custom SQL
Hey, On Feb 10, 4:51 pm, "ludvig.ericson" wrote: > On Feb 10, 1:13 pm, Johan Bergström wrote: > > > Since Django executes my custom SQL before creating indexes, it's > > impossible to achieve something that hooks into initdb/syncdb. I know > > that it is "good custom" to create indexes after inserting data – but > > fixtures in Django is already executed after creating indexes, so that > > can't be the reason.. So, without further ado, what I would like to > > know is if there's a reason to why custom SQL is executed before index > > creation. > > Isn't this doable with initial > SQL?http://docs.djangoproject.com/en/dev/howto/initial-data/#initial-sql > > Testing here with SQLite, it'd seem it runs the custom SQL at the very > last point, so you could actually add some ALTER TABLE statements, I > guess. Again, this is testing with SQLite, and SQLite doesn't do > indexing. Actually it doesn't. I think you just did a reset/sqlall instead of sync/initdb: # cat settings.py | grep DATABASE_E DATABASE_ENGINE = "sqlite3" # python manage.py syncdb Creating table testapp_message Creating table testapp_avatar Installing custom SQL for testapp.Message model Failed to install custom SQL for testapp.Message model: no such index: testapp_message_avatar_id Installing index testapp.Message model Installing json fixture 'initial_data' from '/fixtures'. As you most likely can tell from above, sql/message.sql contains a "drop index ..." operation. (nitpick: SQlite has indexes - you could of course argue their effectiveness :-) > > Maybe I misunderstood? > Perhaps I should've been more verbose :-) Thanks for your input though. > - Ludvig Regards, Johan Bergström --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine port
On Tue, Feb 10, 2009 at 10:36 AM, David Larlet wrote: > > > Le 10 févr. 09 à 05:25, Malcolm Tredinnick a écrit : > > There's also > > simple enough stuff like removing the last vestiges of raw SQL from a > > couple of places (most notable related fields, but that should > > probably > > go after, or in tandem with, a rewrite of related fields to clean them > > up in general). > > That's the goal of #10109. Good to know there is eventually an > interest in this. > > Regards, > David > > http://code.djangoproject.com/ticket/10109 > > > > > David, I think I mentioned this to you, but I believe that by using the new F() objects we can actually remove the raw SQL entirely, I'd need to put some more thought into this(and perhaps Malcolm already has) but it should be possible. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #9344 and policy for small bug reports
> Anybody can review tickets (shouldn't review your own, for obvious > reasons). So if there are patches out there, start going through them. > > The current timing is significant. Once we get a couple of things > knocked off and 1.1-alpha out the door, a few of us (and me, in > particular) will have more time to just dive in and start > closing/commiting/bouncing back tickets. It's not too hard to knock off > 100 in a few days. > That's really encouraging. Thanks Malcolm. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine port
Le 10 févr. 09 à 17:53, Alex Gaynor a écrit : > David, I think I mentioned this to you, but I believe that by using > the new F() objects we can actually remove the raw SQL entirely, I'd > need to put some more thought into this(and perhaps Malcolm already > has) but it should be possible. Alex, I agree with you (not yet tried though), it's only a timing issue. There are two possibilities: moving then reF()actoring or doing both in the meantime/same patch. I adopted the first one because I got no answer to my previous email and that's the blocking point to me, I thought there were more chance that it get commited quickly keeping the patch as simple as possible. Now, if you think it's important to do both and provide some feedback on the way I did the move I'll be glad to work on it. Regards, David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine port
On Tue, Feb 10, 2009 at 12:36 PM, David Larlet wrote: > > > Le 10 févr. 09 à 17:53, Alex Gaynor a écrit : > > David, I think I mentioned this to you, but I believe that by using > > the new F() objects we can actually remove the raw SQL entirely, I'd > > need to put some more thought into this(and perhaps Malcolm already > > has) but it should be possible. > > Alex, I agree with you (not yet tried though), it's only a timing > issue. There are two possibilities: moving then reF()actoring or doing > both in the meantime/same patch. I adopted the first one because I got > no answer to my previous email and that's the blocking point to me, I > thought there were more chance that it get commited quickly keeping > the patch as simple as possible. > Now, if you think it's important to do both and provide some feedback > on the way I did the move I'll be glad to work on it. > > Regards, > David > > > > > From my perspective they don't need to be at once, but there's no point in moving a bunch of code if the new location won't make sense once we remove the raw SQL. I'll take a look at the patch this afternoon and give some thoughts. As for the F(), the question of whether that should be specific to SQL backeneds is interesting, I don't know enough about non-SQL backends to know if that type of query makes sense. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
#5903 DecimalField returns default value as unicode string
Hey all, I recently came across the issue described in #5903 [1] earlier. There are two distinct patches that fix the problem, but at different levels. My inclination is to fix this issue at the model field level and properly override get_default. My feeling is that allowing Decimal objects to pass through force_unicode (when strings_only=True) might cause ill-effects in other parts of Django, but I am not entirely sure (running the test suite with the fix in force_unicode didn't cause any failed test, but that doesn't make it right to me :). I don't see much reason to do so. Perhaps someone can shed some light on this? [1]: http://code.djangoproject.com/ticket/5903 -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #5903 DecimalField returns default value as unicode string
On Tue, Feb 10, 2009 at 7:06 PM, Brian Rosner wrote: > > Hey all, > > I recently came across the issue described in #5903 [1] earlier. There > are two distinct patches that fix the problem, but at different > levels. My inclination is to fix this issue at the model field level > and properly override get_default. My feeling is that allowing Decimal > objects to pass through force_unicode (when strings_only=True) might > cause ill-effects in other parts of Django, but I am not entirely sure > (running the test suite with the fix in force_unicode didn't cause any > failed test, but that doesn't make it right to me :). I don't see much > reason to do so. Perhaps someone can shed some light on this? > > [1]: http://code.djangoproject.com/ticket/5903 > > -- > Brian Rosner > http://oebfare.com > > > > It seems force_unicode is the wrong level to fix this at, and doing it in get_default() is the right place. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #5903 DecimalField returns default value as unicode string
On Tue, Feb 10, 2009 at 7:10 PM, Alex Gaynor wrote: > > > On Tue, Feb 10, 2009 at 7:06 PM, Brian Rosner wrote: > >> >> Hey all, >> >> I recently came across the issue described in #5903 [1] earlier. There >> are two distinct patches that fix the problem, but at different >> levels. My inclination is to fix this issue at the model field level >> and properly override get_default. My feeling is that allowing Decimal >> objects to pass through force_unicode (when strings_only=True) might >> cause ill-effects in other parts of Django, but I am not entirely sure >> (running the test suite with the fix in force_unicode didn't cause any >> failed test, but that doesn't make it right to me :). I don't see much >> reason to do so. Perhaps someone can shed some light on this? >> >> [1]: http://code.djangoproject.com/ticket/5903 >> >> -- >> Brian Rosner >> http://oebfare.com >> >> >> >> > It seems force_unicode is the wrong level to fix this at, and doing it in > get_default() is the right place. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero > I sent that last email off rather hastily, and didn't think about it enough, and of course I've changed my mind :). It seems to me this is the exact purpose of the strings_only kwarg, for when what we want to do is make sure a string becomes unicode, but not to mess with other objects. Further it's clearly how other fields(integer, date, etc.) do it, so that further the argument that that is the correct way to handle it/use strings_only. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Interaction of annotate() and values()
On Tue, 2009-02-10 at 19:43 +0900, Russell Keith-Magee wrote:
> On Tue, Feb 10, 2009 at 1:53 PM, Malcolm Tredinnick
> wrote:
> >
> > On Sun, 2009-02-08 at 15:56 +0900, Russell Keith-Magee wrote:
> > [...]
> >> There is a slight complication, though. The ordering of values() and
> >> annotate() is significant - values() controls the grouping of
> >> annotated values if it precedes the annotate().
> >
> > This is the nub of the problem, isn't it. We possibly messed up here by
> > overloading what values() does/means. :-(
>
> I'm not convinced we messed up - it's a messy situation in general.
> The behaviour as implemented is mostly a requirement of the way
> values() is interpreted. Once you start reducing the set of columns
> that is returned by a queryset, you pretty much have to start
> interpreting that as a grouping. The only other option I can think of
> is to require that once a queryset contains an aggregate, you continue
> to retrieve all the columns, but you only get back the set you
> requested, thereby losing all the optimization benefits of values().
>
> If you can propose a better interpretation for values() in these
> circumstances, it probably isn't too late to do something about it,
> but time is running out fast.
I can't think of anything different. I tossed this around a bit when I
read your original mail, but improvements in one aspect led to
complications elsewhere. You're right that it's probably just a slightly
hairy area to try and smoothly abstract into an API.
>
> > Problem is, adding a new API to specify the grouping order has the same
> > drawbacks as having to write values() twice -- you end up needing to
> > name the fields once for values() and once for the order they group by
> > and then you think about maybe extracting the latter info from the
> > former and we're back where we started.
>
> You also inherit all the validation problems of needing to ensure that
> all the values() columns are also mentioned in the group_by(). It
> could be munged into some interpretation of "working", but it wouldn't
> be pretty as an end user API.
>
> >> However, you can't
> >> mention the annotated column in a values() clause before it is
> >> specified, so are left in a situation where you can't actually return
> >> the annotated value. For example in the query:
> >>
> >> >>> Book.values('title','isbn').annotate(n_authors=Count('authors'))
> >>
> >> n_authors wouldn't be returned in the result set, and there isn't any
> >> way to add it to the returned values.
> >>
> >> So - some options:
> >>
> >> 1) Leave things as-is. Annotated columns always appear in the result
> >> set. This is inconsistent with extra(), and means you can't use
> >> annotated queries in __in clauses.
> >
> > Unintuitive and inconsistent. As much as I'm willing to declare extra()
> > the odd man out for most API consistency arguments and as an example of
> > solid behaviour, I like the current behaviour with
> > extra(...).values(...).
>
> Just to clarify - what exactly do you see as the current expected
> behaviour of extra(select=).values(...)? I started fiddling with this
> last night in the context of ticket #10132, but it doesn't appear (as
> far as I can tell) to be specifically documented. When I started
> messing about with code, I was somewhat surprised that I didn't get
> flooded with test failures.
>
> By way of example, this is what 1.0.X produces:
>
> >>> Book.objects.extra(select={'a':'name','b':'price','c':'pages'}).values('name','pages','a')
> [{'a': u'Book 1', 'c': 11, 'b': Decimal("11.11"), 'name': u'Book 1',
> 'pages': 11}, ...
That looks like A Bug(tm). I wouldn't have expected 'b' and 'c' to
appear there, since values() should describe the full set of values
returned (sans any extra behaviour of the annotate() portion).
If you don't have time or feel motivated to poke at that, assign a
ticket to me. I've had a brain failure somewhere along the lines by the
look of it, particularly in light of the next example.
>
> >>> Book.objects.extra(select={'a':'name','b':'price','c':'pages'}).values('name','pages')
> [{'name': u'Book 1', 'pages': 11}, ...
That looks correct. So it's only when you partially include the extra
values. That's cool (but b0rked).
>
> I couldn't find a test case that covers this usage - every use of
> extra() that I found intersecting with named values() specifically
> included all the extra selected columns in the values() clause. The
> behaviour as implemented seems to walk a weird middle ground between
> including all extra columns, and only including extra columns if
> specifically requested.
>
> To my mind, the second answer is right, but the first result should be:
>
> [{'a': u'Book 1', 'name': u'Book 1', 'pages': 11}, ...
>
> Have I missed something obvious here?
Assuming competence on the part of the guy who implemented it? Could be
an over-evaluation. Nice catch, though, thanks.
Regards,
Malcolm
--~--~-~--~~~---~--~
