Re: Change list default sort modification proposal

[Rock]

My suggestion for handling the UI for multi-column sorts is to allow
the definition
of named sorts in a manner similar to the way that the default sorting
is defined.
With this in place, additional multi column orders can be accomplished
simply
by using this name as a sort selection and applying the corresponding
named sort.

If this is an acceptable approach, I can flesh out the API for it.

On Aug 11, 10:10 pm, Malcolm Tredinnick 
wrote:
> For those, like me, wondering what this proposal was about, it's
> concerning changing sorting in the admin interface to initially use the
> full set of fields specified in Meta.ordering on the model.
>
> What I can't work out yet, due to difficulty in reviewing the patch,
> mentioned below, is whether it allow sorting by more than one column via
> the column-clicking method. That would almost certainly seem to be a
> request that is going to arrive 10 seconds after a feature like this is
> committed, although the difficulty has always been with how the UI works
> for that situation.
>

--~--~-~--~~~---~--~~
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: Change list default sort modification proposal

[Rock]

Yes. I have a project that could use this immediately. Looking forward
to seeing the ticket and a patch I can try out.

--~--~-~--~~~---~--~~
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: Proposal: Composite Foreign Keys

[Rock]

What is the big deal? I was on a gig recently where Django was used
with Oracle. To support model partitioning for selected models, we
munged the generated SQL for model creation to add composite keys and
the partitioning logic. It was a little bit hairy, but once the model
creation was correct, everything else "just worked". No server hacks
or avoidance of the Django ORM was required to run the apps.

Sadly the code was special cased for the specific form of partitioning
used and therefore not suitable for release as open source, but the
code was not exceptionally hard to write. So get to it. If it really
is too tough for you, there are some hotshot Django consultants around
who may have some free cycles on rare occasions and might be willing
to help you.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Considering alternate SQL Code generators

[Rock]

I was taking a look at Ticket #3163 which, when incorporated into
Django, would add a Meta flag to the model which disables SQL code
generation. It occurred to me that on a conceptual level, this fix is
wrong. What would be more generally useful is a dictionary of
alternate SQL code generating plugins. You could then plugin a custom
SQL generator by name in a given model Meta class. With this approach
you could create plugins that would create alternate table formats
such as partitioned tables, or app-specific DB views or such. You
could also create and use a plugin that generates no SQL at all which
would handle the use case targeted by the fix to #3163.

I haven't looked at the code enough to know where this abstraction
layer fits best, but one obvious possibility is to  have each "plug-
in" take the form of a complete alternative db backend. Since this
would then boil down to selecting the DB backend on a per model basis,
this mechanism should probably be co-designed along with the multiple
DB API since there might be some conceptual overlap.

Thoughts would be appreciated before I jump in and do a deeper dive on
this.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Considering alternate SQL Code generators

[Rock]

OK then. Here is my concept for 2 small hooks...

Let the backend do it's thing and create the table creation SQL in the
normal manner. Right before executing that SQL call a hook function,
if present, gets to modify the SQL or change it to None to suppress
the SQL call entirely. There is also a second similar hook for index
creation. I cannot imagine a more minimal approach than that.

If you don't like Meta, maybe these callbacks could be in the model
manager, or perhaps a new class, a model representation factory. I
kinda like the new class approach as creating that class may provide
an opportunity to clean up several aspects of the db backend design
which may be generally useful as Django gets extended to handle
multiple databases and non-relational databases. But this last thought
is really just conjecture based on a cursory look at the code. I may
have different ideas after doing a deep dive.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Considering alternate SQL Code generators

[Rock]

> In any case, you can already do what you want using custom managers. You
> return a custom queryset that generates the query however you like.
> Lifting all that up into Meta doesn't seem necessary to me.
>

Good feedback Malcolm, but I don't understand that last statement. In
the case of partitioned tables for selected models, the model/manager
interaction with the database is unchanged from normal use accept that
there are some optimized options for batch deletion that a manger
class can add. However the main thing that is different in this
particular case is the creation of the tables and the creation of the
indexes. I was not aware that I could handle that with a custom
manager. (The way that I made this work was by creating a custom
version of the sqlreset manage.py command.)

So how do I customize the table creation using the model manager?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Composite Fields

[Rock]

Malcolm,

I strongly concur with the proposed API. It looks like it can be used
to implement future RangeHash partitioning support. Consider:

I have a model to be partitioned that has an IntegerField that will
become the range partitioning value:

week = models.IntegerField() # 1 to 53 depending on the week of
creation

The hash partitioning value is a field that works precisely like "id":

hash_id = models.IntegerField( auto_everything=True ) # (I made
"auto_everything" up as I am not sure precisely what parameters I need
to set in order to make this happen.)

Now I can create my RangeHash partitioning primary key with a
compositeField:

range_hash = models.CompositeField( hash_id, week, primary_key=True )


What I am doing today for my partitioned models is to use the
automatically generated "id" field, but that looks dicey with the
CompositeField since you can't do this:

range_hash = models.CompositeField( id, week, primaryKey=True )

since "id" doesn't exist yet and, by designating this CompositeField
as the primary key, id won't be generated. Rather than try to special
case this situation, ensuring that I can create a field that works
precisely like "id" by hand and then using that seems to be the way to
go.

Rock


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: user-friendly API for multi-database support

[Rock]

FWIW as a possible data point, our team has implemented partitioned
models in Oracle. To control this I added a settings parameter with a
list or models to be partitioned. The actual work is done in the
sqlreset command logic (but really needs to be in the table/index
generation code for SQL creates.) Fortunately nothing else in the ORM
needs to know about the partitioning. (The one exception: a partition
aware truncation function would be a nice addition for supporting
block deletions that line up with the partition boundaries.)

>From my standpoint, a settings based per-model specification mechanism
for database info may have value over and above the multi-db scenarios
currently under discussion.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: user-friendly API for multi-database support

[Rock]

The default setting defines the application-wide db connection.
The Manager mechanism is for overriding the default connection.

Selecting the db via signals makes no sense to me, however a mapping
between apps and databases in settings is worth a moment of thought as
a possible supplement to the Manager approach.

Rock

P.S. for Simon:
I haven't spotted any obvious problems with the proposal so far.
My initial reaction is that I like it. Good work!


On Sep 10, 1:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
> For application-wide db connections, I think it'd be much easier and
> more portable to choose the connection in settings.py rather than in a
> Model.
>
> Manager.get_connection() is a great idea, but would it also make sense
> to allow selecting the db via signals? That way you could make the
> decision without modifying an app.
>
> -Justin
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Composite Primary Keys

[Rock]

One use case for Composite Primary Keys is for setting up database
partitions. In my case I am using Range-Hash partitions with the range
determined by an IntegerField called "ISOweek" and the hash working
off of the "id" field supplied by Django. To allow this partitioning
to work, the primary key must be a composite primary key incorporating
the "ISOweek" and the "id" fields. My versions of the sqlreset and
reset management functions do this while also ensuring that "id" is
marked as unique even though it is not the primary key. This allows a
ForeignKey pointed at my partitioned model to work correctly by
setting "id" as the to_field. (If "id" is not set as unique, Django
and/or the database will fail in its' attempt to set up the full
foreign key relationship.)

The initial version of Composite Primary Keys should not preclude this
scenario, however full support for setting up and managing partitioned
models need not be included at this time. (I plan to help add that
later.) The interesting point is that support for related fields for
the Composite Primary Key is not required in order to support this
particular use case.

Rock


On Aug 28, 8:05 pm, "David Cramer" <[EMAIL PROTECTED]> wrote:
> I'm not quite sure how that relates to Composite Primary Keys?
>
> A ForeignKey would point to multiple internal fields, but it should look
> like it's a single field. At the same time, this would open up the
> possibility for Composite Foreign Keys, which would mean it could point to
> multiple public fields.
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Composite Primary Keys

[Rock]

To be clear, the syntax is:

myfkey = models.ForeignKey(SomeClass,to_field="id")


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: MultiDb status ?

[Rock]

What you are describing is an edge case for the notion of "sharding"
which is the deployment of identically structured DBs where different
batches of users get saved in different databases. (Flickr does this.)

Sharding is a different problem than the more general notion of
supporting multiple databases. It should be easier to accomplish, but
that is just a guess as I am not up-to-speed on the Django internals
with regards to connection management.

I can imagine that a middleware-based solution might be possible. but
it
would require hacking at a level well below the standard APIs. I will
give
this some thought, but I have been focused on partitioning as the way
to
improve scalability and data management for large Django apps.


On Aug 27, 3:40 am, Romain Gaches <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Thinking about switching from a homemade framework to django, I took a  
> look a the MultiDatabaseSupport stuff 
> (http://code.djangoproject.com/wiki/MultipleDatabaseSupport
> ).
> The related code seems to be 2 years old, is this branch still in  
> development ?
>
> I also noticed that the DB parameters are "statically" defined in the  
> settings. I'm actually looking for the ability to connect to a  
> database "on the fly" according to session-related data; would it be  
> possible without too much adapting work ?
>
> The aim is to have a separate database (with the same schema) for each  
> customer account in my app, the customer id being extracted from a  
> session variable.
>
> I'm currently using my own db manager: attaching & detaching databases  
> (SQLite, MySQL), cross-db requests, etc... but django's models are so  
> amazing I'd like to lighten my app with it :)
>
> --
> Romain
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Composite Primary Keys

[Rock]

Ha! It turns out that a to_field option already exists for ForeignKey.
(I did not know that yesterday.) I have just verified that
to_field(SomeClass,"id")
works fine even if the PRIMARY KEY uses multiple columns. However, and
this
is the key point, the id field has to be marked as UNIQUE.

To prove all of this I have created a sqlresetpartition and
resetpartition command
that looks for classes to partition within your settings. It sets up
the required
multi-column primary key, marks the ID field as UNIQUE, and also does
the other
magic to create partitioned tables. (It also creates partitioned
indexes as required.)

This only works for Oracle and the solution is special cased for my
needs, but it
points the way forward. I will look over the partitioning logic for
MySQL when I get
a chance. Maybe by Django 1.5 or so we can include direct support for
partitioned models.

BTW, once I have the models properly created with partitions, none of
my other
django code requires any changes at all. Besides improved performance,
I must
say that it is a thrill to delete hundreds of thousands of old rows in
less than a
second. This is the key feature I needed for my django app.


On Aug 27, 6:27 pm, Rock <[EMAIL PROTECTED]> wrote:
> Well for one thing, if one of the columns happens to be named "ID", we
> should use that for the relatedfields lookup column and that is that.
> (BTW, does your approach allow the Django supplied ID field to be
> combined with some other field(s) to make a multi-column key? This
> would be bang up for future partitioning support.)
>
> Next I would suggest adding a meta model column designation like
> "id_field" to specify a field to use for related classes. This might
> be a good "80/20" solution that could serve for an initial test
> version.
>
> On Aug 27, 5:27 pm, "David Cramer" <[EMAIL PROTECTED]> wrote:
>
>
>
> > Really I'm stuck at an architectural point.
>
> > I have database validation and synchronization done, and the admin is
> > working.
>
> > What is left is more or less handling relatedfield lookups. The issue is,
> > that field's are designed to reference more than one field, so it's a tough
> > design deicision to make on how that should be approached.- Hide quoted 
> > text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Composite Primary Keys

[Rock]

Well for one thing, if one of the columns happens to be named "ID", we
should use that for the relatedfields lookup column and that is that.
(BTW, does your approach allow the Django supplied ID field to be
combined with some other field(s) to make a multi-column key? This
would be bang up for future partitioning support.)

Next I would suggest adding a meta model column designation like
"id_field" to specify a field to use for related classes. This might
be a good "80/20" solution that could serve for an initial test
version.

On Aug 27, 5:27 pm, "David Cramer" <[EMAIL PROTECTED]> wrote:
> Really I'm stuck at an architectural point.
>
> I have database validation and synchronization done, and the admin is
> working.
>
> What is left is more or less handling relatedfield lookups. The issue is,
> that field's are designed to reference more than one field, so it's a tough
> design deicision to make on how that should be approached.
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Composite Primary Keys

[Rock]

Any progress on this patch David? I would be happy to take a look at
whatever you have and perhaps help out with completing the patch.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Easier URL patterns

[Rock]

On Apr 8, 12:55 pm, Derek Anderson <[EMAIL PROTECTED]> wrote:
> to reuse a well-known axiom: "those who don't know regular expressions
> are doomed to reinvent them... poorly"
>

That saying can be countered by this old saw which I find amusing:

"A programmer has a problem to solve and decides to solve it with
regular expressions.
Now there are two problems."


Personally I have no problem with Django's approach, but I sympathize
with those who
think otherwise. Maybe whipping up a wizard would be in order. Hmmm.

Rock

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: newsform Addition

[Rock]

Some thoughts:

Inplementing form.as_items returning a list of form lines would be
nice.
This allows a variety of custom formatting options. Examples:


{% for item in forms.as_items }}{{ item }} , {% endfor %}
<...submit directive...>



{{ item[0] }} -- {{ item[1] }} -- {{ item[2] }}
{{ item[3] }}
{{ item[4] }}




One trick that I use for tiny forms is to define "inline" for li in
the css and then use form.as_ul.
(If necessary you can do this inside a tagged div to prevent the
inlining of other uls.)

This allows trivial one line forms with the submit button on the same
line. Nice and compact.


Rock

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposed refactoring of create_superuser in contrib.auth

[Rock]

I have hacked create_superuser and the management caller so that
I can set username, email and password in settings.py and obviate
the need to input that data when invoking a fresh syncdb. I can
supply details if people are interested. Based on that hack, I
concur that a refactoring is in order.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Arts and entertainment

[rock]

Arts and entertainment
Share your thoughts , videos , webpages , photos and make friends
through a new powerful website.
It's http://goodtolove.com  . You will really enjoy surfing it.As well
the best is that you can make money through this website using google
adsense.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Aggregate Functions

[Rock]

> I'm not opposed to the idea of a simple min/max etc API in addition to some
> mega-aggregate API.

I am completely opposed to this.
What I am trying to devise is a non-mega-aggregate function that
handles 80% of the cases easily.
The sum(), min(), max() etc. convenience functions are _not_ that.

What is that is a function to return multiple aggregates performed on a
single column expression.
If we have that, we have something worthy of putting in MR _right now_
(and a tested patch exists.)

Creating a mega API to handle all the other stuff can certainly wait
for after MR.

Agreed? If not, let's discuss what function would handle 80% of use
cases.


FWIW, Jacob agreed with this approach when I sat beside him as I coded
it up. I consider
him a big player. Meanwhile I am not doing anything else with MR, so I
can take the time to
polish up what I have already coded and then we have something usable
now. It can still be
changed in future releases up to 1.0.

Since I have created one of the largest Django apps (managing over 20
million rows), I am
eager to move to MR as anyone. Some minimal aggregate function support
would be a
huge plus for me and that is why I chose to target that during the
recent Sprint.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Aggregate Functions

[Rock]

Russ,

It seems that no one else has any thoughts about this, so its just you
and me.

First I note that I agree with you about count. I am taking that out.

Next, I disagree about "average". Using the abbreviated SQLish name for
all of the functions except one is bad. Either all of the names should
be expanded or none. I prefer none since the non-standard SQL aggregate
functions must match the SQL provided name precisely. Might as well
make the standard function names do the same.

The get_aggregate() function is really just the shared code behind
sum(), min(), max(), stddev() and so forth. Arguably it could replaced
by get_aggregates() (or whatever better name you might suggest), but
then it will have a lot of extra setup and teardown code that is
unecessary for the simple cases. Perhaps it should be _aggregate () to
discourage end user use, but there are cases where I would want to use
it. Hmmm.

I will admit that using kwargs is more in line with the rest of Django,
but I really dislike the thought that the  mixmaster approach that you
sketched out would be the only interface. I prefer a design that
handles the simplest 80% of the calls trivially with the knowledge that
the other 20% can be accomplished by dropping down to SQL (which, after
all, is how I do the aggregate functions today.) Once we have a good
80/20 design, then a "kitchen sink" approach would be fun to explore
and your suggestions are a good starting point.

Finally, I agree that the name get_aggregate(s) kinda sux but I still
haven't come up with anything better.

Rock


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Extending count()

[Rock]

Russell Keith-Magee posted this in a separate thread:
> Article.objects.all().count() reads quite obviously as the count of
> all articles. However, Article.objects.all().count('title') reads (to
> me) like an inelegant way of saying 'a count of all titles'. This
> isn't what your proposal would return. What you are proposing can
> already be acheived using
>
> Article.objects.filter(fieldname__isnull=False).count()
>
> which, IMHO, reads better, and is more flexible.

I'll buy that. (Jacob and I were also considering the count(distinct
columnname)
SQL syntax and decided not to target that since it was already easy to
combine
distinct with count(). You point out that this logic also holds for
isnull. Point taken.)

I'll rework my patch for 1435 to remove that change.

Rock


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Aggregate Functions

[Rock]

My other changeset developed at this week's Django Sprint is much more
extensive and is best explained by the new section that I am adding to
the DB API docs.

Feedback is welcome.

Rock



Aggregate Functions
===

Aggregate functions perform calculations on columns. Typically
they return a single value. They are in two groups: high_level
and low_level.

High Level Functions


The high_level functions are sum(), min(), max(), avg(), stddev()
and median(). Each takes a fieldname as an argument. The type of
the field is checked for correctness as only certain datatypes are
allowed for each of the high level functions.

sum(fieldname)
---

Returns the sum of the named field. The field must be an
IntegerField or a FloatField. The returned value corresponds
with the type of the column.

min(fieldname), max(fieldname)


Returns the minimum or maximum value of the named field. The field
must be an IntegerField, FloatField or DateField. The returned value
corresponds with the type of the field. (This is a string
representation if the field is a DateField.)

avg(fieldname)
---

Returns the average of the named field. The field must be an
IntegerField or a FloatField. The returned value is a Float.

stddev(fieldname)
--

Returns the standard deviation of the named field. The field must be an
IntegerField or a FloatField. The returned value is a Float.
(Not supported on sqlite3. You get an OperationError exception.)

median(fieldname)
--

Returns the median value of the named field. The field
must be an IntegerField, FloatField or DateField. The returned
value corresponds with the type of the field. (This is a string
representation if the column is a DateField.) Unlike the other
functions in this group, this function does not use the DB
supplied capabilities. It fetches all of the values of the field
ordered by that field and returns the middle value. (If there
are an even number of values, the second of the two middle
values is returned.)

Low Level Functions
---

There are two low level functions: get_aggregate() and
get_aggregates(). They do minimal checking and allow for
powerful queries that potentially return multiple values
and/or combine multiple column arithmetically.

The low_level functions take columnnames instead of fieldnames.
You must do your own conversion from fieldname to columnname
if you are taking advantage of the fieldname mapping. (By
default fieldnames and columnnames match each other and so
most users will not have to worry about this distinction.)

get_aggregate(type,columnname)
--

This function supplies direct support for all database-supplied
aggregate functions. The type parameter is the name of an aggregate
function such as 'SUM', 'VARIANCE' or so forth limited only by
what set of functions your particular database supports. The return
value uses whatever type your database connonically returns. (Most
databases return the same type as the named column, although this
is not the case for some functions such as "avg" or "stddev" which
always returns a Float. Also note that sqlite3 always returns a Float
for all aggregate function.)

Note that the columnname is not explicitly checked for type and
so it is possible to combine columns arithmetically (with care!)
as follows:

Inventory.objects.get_aggregate('AVG','quantity*price')

This returns the average value of the 'quantity' column multiplied
by the 'price' column.

Meals.objects.get_aggregate('MAX','price+tax+tip')

This returns the highest priced meal which is calculated by the
database by adding the 'price', the 'tax' and the 'tip' columns.

(As a repeat warning: Don't forget to get the columnname from your
fieldname if you are using fieldname mapping.)

get_aggregates(types,columnname)


This function allows a single SQL operation to perform multiple
aggregate functions. The types field is an iterable list of
aggregate function names. The columnname is handled in the same
manner as with the get_aggregate() function. For example:

Inventory.objects.get_aggregates(['AVG','MIN','MAX'],'quantity')

The results are returned in an array.

Usage
-

Typical use targets all of the rows in the targeted table.
For example:

Articles.objects.sum('wordcount')

However it is possible to combine the aggregate functions with
judicious filtering. For example:

Poll.objects.filter(question__contains='football').min('pub_date')

Exceptions
--

The most common exceptions encountered when using aggregate functions
are:

FieldDoesNotExist - the columnname is not found.

TypeError - the named column uses an unsupported type.

OperationError - the functype is not supported by the database.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"

Extending count()

[Rock]

I have been sprinting this week with Jacob and others at PyCon.

Here is a small change that I am about to check in that extends the
count() function:

count(self,fieldname="*")

This change in query.py as well as the corresponding funcion in
manager.py extend the count() function. In the default case the
function is unchanged. If a fieldname is supplied, then the SQL query
is changed from COUNT(*) to COUNT(columnname).

The effect is that the count now returns the number of rows where the
named column has a non-null value.


Rock


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---