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 t
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,
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, e
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 plu
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
> 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 parti
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
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 crea
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
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 t
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@goog
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 dat
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
> combi
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 fu
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 pos
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
--~--~-~--~~--
nlining 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
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.
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.
--~--~-~--~~-
> 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.
e 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
nct
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
--~--~-~--~~~---~--
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. Typi
he 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
--~--~-~--~~~---~--
24 matches
Mail list logo
