Re: Change list default sort modification proposal
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
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
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
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
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
> 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
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
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
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
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
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 ?
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
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
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
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
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
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
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
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
> 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
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()
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
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
Extending count()
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 -~--~~~~--~~--~--~---
