Right, thanks for the clarification! I see now that it has been added
to the tutorial as well, which is good:
"In this tutorial, we'll create our poll app in the mysite directory,
for simplicity. As a consequence, the app will be coupled to the
project - that is, Python code within the poll app w
sorry, forgot to include the group_by columns in the select clause:
> qset.values('field', 'field2', 'field3__sum', 'f4__count', ...) < = >
> SELECT field, field2, SUM(field3), count(f4) FROM some_table GROUP BY field,
> field2;
--~--~-~--~~~---~--~~
You received
On 4/13/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 4/13/07, Honza Kr�l <[EMAIL PROTECTED]> wrote:
> > the queryset refactoring must (well, should) happen before aggregation
> > support. After the refactoring, it should be relatively easy to put in
> > the aggregations.
> >
> > see:
>
hi,
i noticed that [] is not in the EMPTY_VALUES against which data is
validated in newforms fields' default clean() function; this makes
fields which usually return lists raise the ValidationError 'This field
is required.' themselves instead of relying on super(). an example of
this behavior is
On 4/13/07, Anders Olsson <[EMAIL PROTECTED]> wrote:
> portable and decoupled from the project where it is used. But doesn't
> the project being the top level python package make it almost
> impossible to move an app from a project to another without modifying
> the import statements?
If you insi
This is something I've found confusing ever since my first contact
with django, reading the tutorial - all this emphasis on apps being
portable and decoupled from the project where it is used. But doesn't
the project being the top level python package make it almost
impossible to move an app from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thx for your clarification.
Russell Keith-Magee a écrit :
> Indexing a fields makes searches over that field faster. Slug fields
> are the very definition of a searchable, indexable field - the most
> common use case for a Slug is as part of a URL
Maybe because there is a high change that you will try to find rows based on
this SlugField, so in common cases this INDEX will be nice.
Also it's documented on
http://www.djangoproject.com/documentation/model-api/#slugfield that this
field has an implicit db_index=True, BUT you can always pass db
> When I use a SlugField in a model,
> an index for this field is create in postgres.
>
> Why ?
Indexing a fields makes searches over that field faster. Slug fields
are the very definition of a searchable, indexable field - the most
common use case for a Slug is as part of a URL scheme. So,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
When I use a SlugField in a model,
an index for this field is create in postgres.
Why ?
(config : django 0.96 / postgresql )
A++ Xav.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http
On Fri, Apr 13, Wolfram Kriesing wrote:
> Since I have tried creating forms from models, fields and all the
> magic I finally ended up creating my forms by hand and also connecting
> the data to it by hand, that is not DRY but it allows for most
> flexibility, which I found to need most of the ti
This is great stuff. Is there some place where one can see the
proposed dates when such branches would be merged to the trunk? I will
definately stop working on my project due to this, I would not want to
rewrite all my code to use newforms-admin.
Thanks
--~--~-~--~~~--
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
>
> Oh, in addition I was wondering what the 'right' way to do this would
> be at the current time?
very nice that you are bringing this up. I am also just waiting for
the wholy grale on this one.
Since I have tried creating forms from models, fields and
13 matches
Mail list logo
