On 2/10/07, David Abrahams <[EMAIL PROTECTED]> wrote:
>
>Use natural operators for filtering, excluding, and attribute
>access.
> How about it?
Some immediate problems:
- Your syntax works for < > <= >= and ==; but what about all the other
Django query operators? How do you come up with
Hi all,
I've been working on the test system again, trying to get #3162 merged
in. The ticket itself is no big drama, but it does expose a larger
problem with the i18n system that is causing some drama. I18n isn't
really my specialty, so I'd appreciate any assistance in sorting this
problem out.
On 2/10/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Hey Adrian,
>
> I have some concerns about this changeset.
...
> Since the idea is that Django's test framework can also be used to test
> our own applications and projects, I think we need to respect what is
> already in this setting a
On 2/10/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 2/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > Open tickets. Reporting problems is what tickets are for, and there is
> > already a value of documentation for the component of a problem repor
On 2/10/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Do we need an "enhancement" resolution, or some other way of saying
> "some day, maybe"? The benefit of this is keeping the very low priority
> stuff out of the queue of things needing attention. Then we can point
> enthusiastic bods at
On 2/10/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-02-09 at 23:59 -0600, Adrian Holovaty wrote:
> > I'm +1 on that change, despite its backwards incompatibility. It
> > doesn't require much brain power to add import statements to code, so
> > it wouldn't be a *huge* inconve
On 2/18/07, oggie rob <[EMAIL PROTECTED]> wrote:
>
> > I find it useful to have the {% for %} tag syntax extended so that one can
> > write:
> > {% for a,b in L %} meaning the obvious thing
+1.
> > Also (maybe more contentious):
> > {% for i in L1,L2 %} meaning what one would write in python
On 2/22/07, Sandro Dentella <[EMAIL PROTECTED]> wrote:
>
> The reverse is not true, you don't get a widget for the user in the form
> created for Group.
>
> Why that?
Mostly historical. In the bad old days, the Django query syntax didn't
support queries across the reverse direction of relat
On 2/26/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 2/25/07, Rubic <[EMAIL PROTECTED]> wrote:
> > In keeping with the overall theme of testing at this
> > year's PyCon, it would be nice to have integrated
> > testing (fixtures, ticket #2333) brought to resolution.
>
> I really, really,
On 2/26/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 2/26/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > AFAIK, it is finished, just waiting for Adrian's ok. Is there
> > something missing that I'm not aware of?
>
> Oh, I thought t
On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> What would the new (QuerySet) world order look like
>
> What I propose to do is to split out the SQL construction from the body
> of QuerySet and make it into a separate class. This c
On 2/26/07, Massimiliano Ravelli <[EMAIL PROTECTED]> wrote:
>
> Hi Russ,
> I'm using your latest patch (ticket #2333) in my applications:
> I find it useful and extremely fast !
Glad you like it.
> I think that a different exit code when one or more tests fail would
> really
> be helpful in case
On 2/26/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> > I think that a different exit code when one or more tests fail would
> > really
> > be helpful in case of automated tests.
>
> http://code.djangoproject.com/ticket/3253
>
> ;-)
Oops :-). To make up for my boo boo, please accept [4608]
On 2/27/07, Mike Axiak <[EMAIL PROTECTED]> wrote:
>
> Anyway, I'm about to overload the Q object. In this new object, Q' (i
> still haven't got a good name for it), will look up the tree (or down)
> for any ORs, and switch the join type from 'INNER JOIN' to 'OUTER
> JOIN'.
> I may have to overload
On 2/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> On Feb 26, 3:15 pm, "Matthew Flanagan" <[EMAIL PROTECTED]> wrote:
> > Add to that
> >
> > 3. Finish Schema evolution and merge to trunk
> > 4. Finish Row level permissions and merge to trunk
>
> Actually, I think that the row level perm
On 2/27/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>
> On 2/27/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> >
> > I might have missed something in the discussions somewhere, but I
> > don't think this is true. The newforms-admin is all about
On 2/27/07, Massimiliano Ravelli <[EMAIL PROTECTED]> wrote:
>
> On 26 Feb, 13:31, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> > #3253 has a working patch with documentation. I've closed yours as
> > duplicate of #3253.
>
> Hi Micheal, Hi Russ
>
> >From ticket #3253:
> "I didn't check whether it
Hi all,
Adrian has finally had a chance to look at, and approve the acceptance
of, the test fixtures patch. I sat down tonight to check in the patch,
did a last little check, and hit a snag - the trunk model tests break
under MySQL. Personally, I'm a Postgres jockey, so I need some
guidance from
On 2/28/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 2/27/07, Seattle Daniel <[EMAIL PROTECTED]> wrote:
> > As I read it, there is not a way to force InnoDB to check constraints
> > at commit. And once there is it will be quite some time before the
> > mass of MySQL instances support it
On 2/28/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I wanted to use UUID as primary key in my models. Since Model doesn't
> have any add() method, I have to do it like this:
For the future - this question should be asked on the users list. The
developers list is for discussion of
On 2/28/07, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
>
> Django is, as I have
> been told, database independent. And Django is working fine with
> MySQL, lets keep it that way.
Well, no, MySQL isn't working fine. Like I said, [4610] didn't break
MySQL - it just revealed a problem that has alw
On 3/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 3/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > How close are we to tagging the tree for 0.96?
>
> Close :)
>
> There are still a couple bugs to be knocked off, and a couple
> documentation things I'd like to see shored up, thoug
On 3/10/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> Howdy folks,
>
> I just created ticket #3688 [0]. It introduces a change we've been using
> internally for a few weeks and I thought might be useful to other users.
Thanks for the contribution, Benjamin, but the existing behaviour (or
lack
On 3/10/07, Tristan <[EMAIL PROTECTED]> wrote:
>
>
> Hi Russ:
> Do you have news about Oracle Sprint stuff? Will this be included in
> 0.96?
I don't have any particular knowledge of the Oracle sprint work. I
believe Jacob was coordinating that effort, but I could be wrong on
that front.
Yours,
R
On 3/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> On the pre-0.96 note - I'm currently working on a more comprehensive
> test suite for the serializer. I don't know that there are any
> specific problems, but my experience so far has with me feeling that
> t
On 3/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-03-08 at 04:09 -0800, Simon G. wrote:
> > Good Evening Djuggernauts,
> >
> > I've spent some time looking over the email related tickets in Trac,
> > and think I've got them sorted out a bit. I'm hoping to spur some
> > disc
On 3/13/07, Simon G. <[EMAIL PROTECTED]> wrote:
>
> Does anyone object/disagree if I move all the tutorials off the
> DjangoResources page (1), to a new page (2) to give them some more
> room to 'breathe'? I'll take a crack at categorising them too - pre-
> MR, components, etc.
Sounds like a goo
Hi all,
On the users list, Gijs <[EMAIL PROTECTED]> has raised the idea
of dynamic fixtures. For example, Rails allows the use of embedded
Ruby in a fixture file, so that:
<% for i in 1..1000 %>
fix_<%= i %>:
id: <%= i %>
name: guy_<%= 1 %>
<% end %>
would define a fixture with 1000 instanc
On 3/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> > would define a fixture with 1000 instances of an object.
>
> I have to ask a dumb question first: what is this sort of thing useful
> for? More importantly, why can't it be done by using existing our
> existing serialisation framework
On 3/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> When I was talking about using the serialisation framework before, I
> wasn't actually thinking of going via the database: just serialising
> using the lower-level stuff from dictionaries or whatever. Admittedly
> some helper functions
On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I think the serializers should have a option for serializing model
> properties
>
> This is set to design decision needed, does this seem like something
> django needs?
>
> http://code.djangoproject.com/ticket/3661
In the example you gi
On 3/19/07, Àngel Àlvarez <[EMAIL PROTECTED]> wrote:
>
> File
> "/usr/lib/python2.4/site-packages/Django-0.95.1-py2.4.egg/django/db/models/query.py",
> line 835, in lookup_inner
> raise TypeError, "Cannot resolve keyword '%s' into field" % name
> TypeError: Cannot resolve keyword 'routepointl
On 3/20/07, hoamon <[EMAIL PROTECTED]> wrote:
>
> i have no idea about keywords of this question, so i can't search the
> answer of this question or the django document.
Please refrain from double-posting messages to Django-users and
Django-developers. If you have a question about Django, please
On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I am in no way saying this should be default behaviour of the
> serializers, but as a option, making a own serializer for theese cases
> is possible, but this makes it a lot of more work for something that
> could be so DRY.
Again, what
On 3/22/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
>
> For full details, please see the ticket at:
> http://code.djangoproject.com/ticket/3779
>
> Can anyone else confirm this so I can be sure it's not some wonky
> configuration on my end?
Hi Ben,
Confirmed, and fixed in [4780]. Thanks for t
On 3/27/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I tried to merge the
> multiple-db-support branch onto my working copy, merging r3198:HEAD as 3198
> was when the branch was created, but it failed and i ended up with a lot of
> < .working and similar dotted around the files.
Th
Hi all,
I just noticed that my RSS reader has stopped providing notifications
of new and closed tickets.
The problem appears to be caused by Django's RSS feed. For example, if
you follow the RSS link at the bottom of the the default timeline page
http://code.djangoproject.com/timeline
you get
On 3/30/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> Can a core developer please check in the missing file from the ticket
> (it's in the patch, it just wasn't committed it seems):
> http://code.djangoproject.com/ticket/3799
That was me - I forgot to svn add the new file. Apologies to all for
t
Hi all,
This discussion is about _very_ trivial change, but it would break
backwards compatibility, so I want to get some consensus before I
commit anything.
Ticket #3532 ( http://code.django.project.com/tickets/3532 ) discusses
the spaceless templatetag. In particular, there has been a request
On 3/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-03-31 at 10:59 +0800, Russell Keith-Magee wrote:
> [...]
> > 1) Is there a valid use case out there for the default 'leave 1 space'
> > behaviour that I am missing?
>
> Reada
On 3/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-03-31 at 12:19 +0800, Russell Keith-Magee wrote:
> > Ok - initial opinion appears to be anti configurability and anti
> > changing the default. Another option is to introduce a different tag
&
On 3/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Hey Russell...
>
> Any suggestions on a good way to split up test files?
>
> Currently, regressiontests/forms/tests.py is over 4100 lines long and is
> a real pain to debug problems. Since it seems to be just one big
> docstring, I can'
On 3/31/07, Espen Grindhaug <[EMAIL PROTECTED]> wrote:
>
> Hello
>
> I have already made a ticket about using custom managers in reverse
> relations ( http://code.djangoproject.com/ticket/3871 ), but it seems
> to have gotten no attention. That's is just too bad, because this is a
> feature I know
On 4/1/07, M Harris <[EMAIL PROTECTED]> wrote:
>
> I am currently planning an installation of django on my opensuse server and
> would like advice on caveats (potholes, etc).
This question should be asked on the django-users mailing list.
Django-developers is for discussion of changes to the Djan
On 4/1/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 4/1/07, James Bennett <[EMAIL PROTECTED]> wrote:
> > Sounds good to me. Based on that, I'll whip up a US SSN field, and I
> > think that following this it will:
> >
> > 1. Validate the number of digits (9).
> > 2. Validate that the numbe
On 4/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 4/1/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> > I'm not sure if there's a ticket for this, but I remember talk about
> > it being an unnecessary wart which was going to be removed eventually.
> > Is it in the 1.0 plan?
>
> Yes, I'd li
On 4/2/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Is there an easy way to say "today - 3 days" just using the datetime
> module? I can't think of one off the top of my head that isn't as
> complex as LazyDate(), but that may be because it's Monday.
How about:
lambda : datetime.now() +
On 4/3/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> Can we please have some discussion over adding "required" and "error"
> HTML classes to fields in newforms as_ methods?
>
> Two tickets of relevance:
> http://code.djangoproject.com/ticket/3512
> http://code.djangoproject.com/ticket/3515
Hi Ch
On 4/4/07, Wolfram Kriesing <[EMAIL PROTECTED]> wrote:
>
> I have summarized the problems I had with django's json serializer
> here
> http://wolfram.kriesing.de/blog/index.php/2007/json-serialization-for-django
> i would be very interested if I might be doing something completely
> wrong or if t
Hi all,
I've been hunting bug #3915, and I think I've found the cause, but I
can't see an obvious solution. AFAICT, the problem only exists with
Postgres, because it's the only backend that uses sequences for
primary key allocation.
Here's a sample Django session. MyModel is a some random model
On 4/4/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> All we can do is set the
> next sequence value to one greater than the largest existing pk value;
> there's no way to tell the automatic sequence to skip a particular value
> in PostgreSQL.
That's the solution I was hinting at without t
On 4/4/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On 4/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> ...
> > AFAICT, the problem only exists with
> > Postgres, because it's the only backend that uses sequences for
> > primary key allocati
On 4/6/07, Will McCutchen <[EMAIL PROTECTED]> wrote:
>
> But what does the following mean?
>
> {% ifequal a x and b y or c z %}
>
> Should all of the clauses be required to use the same operators? Ie,
> must they all use "and" or must they all use "or"? Maybe I'm just
> missing the simple logic
On 4/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Remarks/trolls/thoughts welcome :)
Straight out name churning isn't open for debate. Is ForeignKey the
best name for a n-1 relation between models? This is a value
judgement, Ultimately, it doesn't matter if ForeignKey is renamed
WolfWhi
Hi all,
A few backwards incompatible changes have been raised on the list in
the last week or so:
- Removing auto_add_now and auto_add
- Removing LazyDate
- Renaming localflavour.usa to localflavor.us
This raises the question - do we have any particular timeline or
strategy for making these ch
On 4/7/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> Attached is a patch that re-implements __repr__ using an iterator over the
> object. Thus, SortedDict's are displayed properly in the Python shell.
Hi Forest,
The best way to make sure this isn't forgotten is to get it into the
ticket system
Hi all,
I'm trying to tie up the loose ends of the auto_now/auto_now_add
discussion so that I can bang together a patch.
auto_now_add can be pretty much replaced with default=datetime.now.
Honza raised the issue that the two aren't completely identical
because if you supply a value for the field
On 4/10/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 4/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > 2) (Jacob) Add a child class of DateTimeField that defines the
> > required pre_save behaviour.
> >
> Solution #2 seems the cleane
On 4/12/07, Christopher <[EMAIL PROTECTED]> wrote:
First off - User queries (like this one) should be directed at
Django-users, not Django-developers. The developers list is for
discussion of the internal development of Django itself.
That said...
> I have no idea what has gone wrong but here i
On 4/13/07, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> I didn't see anything about aggregate support in
> VersionOneFeatures[1], are people still hung up about the syntax, or
> is anyone hacking on this? It's been mentioned a couple times since
> PyCon, but what's the status?
Many proposals have b
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:
> http://code.djangoproject.com/ticket/3566
I didn't notice this ticket
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:
> http://code.djangoproject.com/ticket/3566
Ok; I've had a chance to loo
> 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,
Hi Honza,
Over the weekend, I tried responding to our last message inline, but
my response kept getting long and confused. So, I've summarized my
thoughts. I have three problems with your proposal:
- Your approach is very group/SQL-centric, rather than being
object/goal-centric. I would expect t
On 4/16/07, Armin Ronacher <[EMAIL PROTECTED]> wrote:
>
>
> Hoi,
>
> -1 for the database interaction. The debugger should also work if the
> database is fucked up.
Mind the language, please. This is a formal mailing list discussing serious
issues. Keeping the language civil is just one way we ens
On 4/16/07, Honza Král <[EMAIL PROTECTED]> wrote:
> besides, Django's queryset is very SQL-centric so far
To a large extent, yes, but no in some very important ways.
Article.objects.all() isn't the least bit SQL, although the mapping to
SQL is obvious. Preserving the object flavor of the ORM is
On 4/17/07, Gulopine <[EMAIL PROTECTED]> wrote:
> My main questions are these:
>
> * Am I right in thinking that Django's to_python method should be used
> for type coercion, rather than relying solely on backend drivers?
Historically, to_python existed for the manipulator framework to
convert t
On 4/18/07, Gulopine <[EMAIL PROTECTED]> wrote:
>
> On Apr 17, 9:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
> I don't know what
> other field types there might be in the future, but it seems like a
> stretch to think that it's u
On 4/19/07, jbronn <[EMAIL PROTECTED]> wrote:
>
> The GIS branch (GeoDjango) is interested in type coercion.
> Specifically, PostGIS returns geometries as hex strings to the client
> -- it would be preferable to have this come into the model as either a
> different type of string like WKT ("POLYGO
On 4/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Understand that I don't feel entitled to a response, just that I
> figured if *I* were working on or interested in SQLServer support for
> Django I would act on my own enlightened self-interest and take up the
> offer for assistance imme
On 4/22/07, Rico <[EMAIL PROTECTED]> wrote:
>
> I d like to show you
> http://www.morecute.com
It's great that you're enthusiastic about your new Django project, but
please refrain from spamming the developers mailing list. The
developers list is for discussing the internals of Django.
Yours,
Ru
On 4/27/07, Nicola Larosa <[EMAIL PROTECTED]> wrote:
>
> Ben Godfrey wrote:
> > It was very hard to trace this to the Session.get_decoded method and it
> > felt like a bit of a slap to find all pickle.loads exceptions being
> > dropped silently. Is this really the best thing to do? Surely it would
On 4/28/07, David Elias <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee escreveu:
> > On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I'm afraid I don't see the benefit of what you are proposing. The
> > serialization framework exis
Hi all,
Two suggestions about the newforms API:
1) Is there room for a 'fields' argument on form_for_instance and
form_for_model - a list of field names that you want included on the
form (defaulting to None, meaning the full list), so that it is simple
to create a form with a subset of a model'
On 4/30/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> Regarding suggestion 1:
> You can do that already by providing a formfield_callback function. I
> made a helper to create a callback function to exclude or only include
> certain fields:
> http://www.djangosnippets.org/snippets/209/
This is a
On 4/28/07, David Elias <[EMAIL PROTECTED]> wrote:
>
>
>
> On Apr 28, 2:48 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
> > The open question in my mind is where the serialized data goes - do we
> > put it into the fields block, or do we
On 5/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Alright, perhaps the URL reverse lookup function has something to do
> if a valid view exists. Hope I didn't waste anyones time, it does seem
> to be working now.
Glad you sorted out your problem. In future, could you please direct
queri
On 5/9/07, misho <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> Maybe I'm at the wrong place but you'll never know :) , so I'll try...
Yes, you're asking in the wrong place.
This is the mailing list for discussion of the internal development of
Django. If you're looking to offer people a job working
On 5/10/07, Mike Axiak <[EMAIL PROTECTED]> wrote:
>
> I have created a ticket specifically for newforms-admin and
> edit_inline (#4255).
>
> I'd like to bounce ideas around in there, if people would be willing
> to talk. I would partially be willing to do some implementation, but
> don't want to w
On 5/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> (quite a lot) :-)
>
Hi Brian
The primary design use case for Django development is clean room
development of a new web based application. This is what it was
originally designed for, and there is plenty of evidence around to
suggest th
On 5/11/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> >
> > I realize that you can subclass the form class returned by the
> > form_for_ methods and delete the fields you don't want, but
On 5/11/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 5/10/07, Sebastian Macias <[EMAIL PROTECTED]> wrote:
> > Do any of you guys when the django-admin.py updatedb command will be
> > completed? updatedb is basically all django is missing for me and many
> > developers at the company I work
On 5/11/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> On 5/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> >
> > I've got a working implementation and some proof-of-concept tests;
> > would you like me to clean this up and push it into t
On 4/23/07, David Danier <[EMAIL PROTECTED]> wrote:
>
> > Just use datetime.now without the function call parentheses.
>
> Know this, doesn't work for newforms (initial value).
>
> I added a ticket (including a patch) to fix this:
> http://code.djangoproject.com/ticket/4018
FYI - David's fix was
On 5/14/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > 2) I realize that there are historical (i.e.,
> > manipulator/pre-magic-removal related) reasons why reverse ForeignKey
> > and M2M relat
On 5/15/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> Has anyone noticed a fairly recent order of magnitude slowdown in how
> long it takes to run the django test suite? I used to get times of
> about 14 seconds around March (at PyCon) but it's taking ~150 seconds
> now. It's quite possibly
On 5/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-05-15 at 12:29 +0800, Russell Keith-Magee wrote:
> > >
> > Yes Virginia, there has been a test slowdown :-)
> >
>
> Another data point: there's been almost a 100% slowdown -- fro
On 5/15/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> > It happened around mid January, as a result of the tests that use
> > fixtures. Every time a fixture test is executed, it flushes the
> > contents of the database. Flushing is a
Hi all,
I originally posted this in django-users as the tail end of a longer
discussion, but in retrospect, this is probably a better forum.
I have been looking at the code for function_get_sql_clause() recently
while working on a patch for quoting behaviour for subselects in
"tables" clauses (n
Point taken with the criticism; it isn't a particularly compact syntax.
I wasn't really proposing it as an ideal solution; more of a solution
that could be achieved with very little coding effort. It just struck
me as an elegant internal symmetry that wasn't being exploited.
However, the reason I
Hi all,
I have a few suggestions that I think could increase the the
capabilities and expressiveness of Django DB query syntax. The
modifications are aimed at increasing usage of Django DB syntax (in
preference to embedded raw SQL), and increasing the range of SQL
queries that can be expressed in
> > 2) A 'columns' keyword to restrict column returns
> This already exists; look at the get_values() function:
Right idea, not quite the complete implementation. 'fields' only
applies to get_values, and the 'fields' kwarg isn't utilized by the sql
query itself. The SQL query still retrieves all
On 12/19/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> There are quite a lot of changes in this area being considered in the
> magic-removal branch.
I figured as much. Is there any sort of estimated timeframe for the
merge of the magic-removal branch into the trunk?
> Here are a few example
Hi,
At present, all Django DB query functions accept and use kwargs to
construct queries. All top level kwargs queries are then AND'ed
together.
Given that the (relatively) new Q() syntax for query construction
doesn't require the top level kwarg, doesn't it make sense to allow
unnamed *opts par
Hi,
DB kwarg queries can traverse many-many and many-one relationships; if
this is done, the parse_lookup function works out the required table,
and constructs a join and where clause as required.
However, if a query contains two queries over the same relationship,
the secondary table will be jo
Hi,
Can anyone suggest a use case where you would want to generate a list
of objects that was NOT distinct?
To my eyes, the DISTINCT keyword is an artefact of a relational world,
which serves no real purpose in an object world. In an
object-relational wrapper, which should be returning a list of
Hi Eugene;
I say it is an artefact of a relational world because the very fact
you are using an object-relational mapping means that a certain subset
of SQL queries are either impossible or non-sensical. I think the use
(or rather, the non-use) of DISTINCT falls into that category.
For example,
On 12/28/05, hugo <[EMAIL PROTECTED]> wrote:
> Look at get_values - it will return only those columns that you specify
> you want to get.
Ah - thats the use case I was missing. I withdraw my suggestion.
Thanks,
Russ Magee
On 12/28/05, Tom Tobin <[EMAIL PROTECTED]> wrote:
> Thoughts? Am I just being paranoid? :-)
Hey - you're not being paranoid if they're _actually_ out to get you :-)
Seriously: As far as I can see, yes, you're being paranoid (caveat:
IANAL either)
>From http://dojotoolkit.org/community/licens
Hi all,
On 12/28/05, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Given that the (relatively) new Q() syntax for query construction
> doesn't require the top level kwarg, doesn't it make sense to allow
> unnamed *opts parameters as well as **kwargs in query
901 - 1000 of 2850 matches
Mail list logo
