I remember my beginner times with django, i was searching for limit()
until I had to remind myself multiple times that you have to use [x:y] for it.
limit() seemed the reasonable straightforward thing ... and thats what
i am used to from python
but this time it was different
Providing limit() wou
On Tue, Dec 04, Gary Wilson wrote:
> And I say QuerySets are more like lazy-evaluated lists. lists are iterable
> and can be sliced.
I think this hits the point.
What do you think about this: a QuerySet fetches a chunk of elements, say
100, as soon as you request at least one? So aQuerySet[0]
On Dec 4, 2007 10:00 AM, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> On Tue, Dec 04, Gary Wilson wrote:
>
> > And I say QuerySets are more like lazy-evaluated lists. lists are iterable
> > and can be sliced.
>
> I think this hits the point.
>
> What do you think about this: a QuerySet fetches
Am Montag, 3. Dezember 2007 16:04 schrieb Marty Alchin:
> There is one other question I've been meaning to ask for a while. As
> would be expected, this FileField work adds a good amount of code to
> db/models/fields/__init__.py, including 3 new classes, which aren't
> even Fields themselves (but
Simon - These are GREAT!!! Ideas. The regular expression based URL
dispatching replacement has been something I personally have been
thinking about for some time. I would be interested in helping with
this If you put together a proposal. One URL implementation worth
considering is "Routes" ( htt
another thing i jsut ran into:
this causes an IndexError
Model.objects.filter(something)[0]
you have to add the colon before the 0
Model.objects.filter(something)[:0]
the limit(0) would not bring this error, it would not let
first-time-users run into this problem
another 2 cents
wol
On Tuesday 04 December 2007 07:25:31 Gary Wilson wrote:
> Sort of my point. Since filter() and [:] both return QuerySets why
> should they be any different:
>
> UTPerson.objects.all().filter(name__startswith='a')[:10]
1) This, logically, should return the first ten people whose 'name'
starts w
you are right!
lol, trapped myself nicely ... happens when you dont think :-)
thx
wolfram
On Dec 4, 2007 3:57 PM, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Tuesday 04 December 2007 14:41:07 Wolfram Kriesing wrote:
> > another thing i jsut ran into:
> >
> > this causes an IndexError
> >
On Tuesday 04 December 2007 14:41:07 Wolfram Kriesing wrote:
> another thing i jsut ran into:
>
> this causes an IndexError
> Model.objects.filter(something)[0]
> you have to add the colon before the 0
> Model.objects.filter(something)[:0]
> the limit(0) would not bring this error, it
Hi!
I've seen ticket #4339 ( http://code.djangoproject.com/ticket/4339 )
about allowing django users to create FileFields or ImageFields that
overwrite files with same name.
The ticket is in design decision needed. It's a little change, that
just add an extra feature and is not backward incompat
On Dec 4, 2007 12:57 AM, Gary Wilson <[EMAIL PROTECTED]> wrote:
> But what would the situation be with a new limit() method...
>
> objects = MyModel.objects.filter(site=1)
> first_one = objects.limit(1)
> do_something_special(first_one)
> return render_to_response('t.html', {'objects': objects, 'f
2007/12/4, Adrian Holovaty <[EMAIL PROTECTED]>:
> No -- I guess I didn't explain myself well enough. In this case, I
> wouldn't use limit(). I have two goals:
>
> * Retrieve all objects in the table.
> * Do something special with the first one (once the whole list has
> been retrieved).
>
Hi,
On Tue, Dec 04, 2007 at 10:18:11AM -0600, Adrian Holovaty wrote:
> On Dec 4, 2007 12:57 AM, Gary Wilson <[EMAIL PROTECTED]> wrote:
> > But what would the situation be with a new limit() method...
> >
> > objects = MyModel.objects.filter(site=1)
> > first_one = objects.limit(1)
> > do_something
Hi,
Replying to self.
On Tue, Dec 04, 2007 at 11:25:42AM -0500, Forest Bond wrote:
> objects = MyModel.objects.filter(site=1).fetch()
> first_one = objects[0]
Incidentally, qs.fetch() need not be equivalent to list(qs). It could just
trigger qs to cache the results of the query and return qs it
Any time I see "FileField" in a subject line, my ears perk up, so I'll
put in my thoughts on this subject.
On Dec 4, 2007 10:43 AM, Marc Garcia <[EMAIL PROTECTED]> wrote:
> I've seen ticket #4339 ( http://code.djangoproject.com/ticket/4339 )
> about allowing django users to create FileFields or I
I agree on not commiting patches to a module that will be rewrite
soon. I hope that you find the way to allow that feature on new
version.
Thanks,
Marc
On Dec 4, 5:29 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> Any time I see "FileField" in a subject line, my ears perk up, so I'll
> put in
One other question (for now). I just did a ticket search for
FileField, and I found a few tickets (#5655, #5619 in particular) that
seem to be legitimate beefs, but their patches rely on pre-#5361 code.
Should I consider #5361 to be on par with Malcolm's (many) refactors
and try to roll fixes for
On Dec 4, 2007 11:46 AM, Marc Garcia <[EMAIL PROTECTED]> wrote:
> I agree on not commiting patches to a module that will be rewrite
> soon. I hope that you find the way to allow that feature on new
> version.
I guarantee you it'll be possible. I just hate how ugly it'll look,
unless I find a way
I've run into a problem with get_or_create() with respect to concurrent
access of the DB, and I have looked at the list archives for advice. I
found some discussions a while back regarding other's problems but no
acceptable solution was ever implemented. I have another proposed
solution that
On 12/4/07, Travis Terry <[EMAIL PROTECTED]> wrote:
> Previous proposals to address this issue involved adding either a thread
> lock or a DB table lock around the get_or_create() call. Both of these
> are unacceptable. The thread lock does nothing to prevent the problem
> when using multiple fr
On Dec 4, 2007 3:08 PM, Travis Terry <[EMAIL PROTECTED]> wrote:
>
> I've run into a problem with get_or_create() with respect to concurrent
> access of the DB, and I have looked at the list archives for advice. I
> found some discussions a while back regarding other's problems but no
> acceptable
James Bennett wrote:
> Ultimately, the database is the only location from which you can solve
> this problem, because only the database can reliably know when these
> situations are occurring. Solutions implemented outside the DB are
> essentially doomed from the start.
>
> Similarly, an applicat
Unfortunately, no. I understand transaction isolation levels. By the
way, I'm using MySQL InnoDB which has similar isolation level settings
to PostgreSQL. Regardless of the isolation level, the one of the two
concurrent creates will fails. They are atomic and add data that will
voliate a UN
On Dec 4, 2007 4:21 PM, Travis Terry <[EMAIL PROTECTED]> wrote:
>
> Unfortunately, no. I understand transaction isolation levels. By the way,
> I'm using MySQL InnoDB which has similar isolation level settings to
> PostgreSQL. Regardless of the isolation level, the one of the two
> concurrent
On Dec 4, 2007 11:21 AM, Travis Terry <[EMAIL PROTECTED]> wrote:
> Otherwise, if it lets the exception escape, then everywhere I call
> get_or_create() will have to implement a very non-DRY piece of identical
> code to handle the situation.
>
> Travis
>
Couldn't you implement your own DRY soluti
On Dec 4, 2007 2:21 PM, Travis Terry <[EMAIL PROTECTED]> wrote:
> exception escape, then everywhere I call get_or_create() will have to
> implement a very non-DRY piece of identical code to handle the situation.
I won't get into the issue of whether this should or shouldn't be in
core, but you mo
On 12/3/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> > Didn't see one so I opened one, #6117. From a brief look it seems to me
> the
> > way to determine what has changed would be to compare the cleaned_data
> > values for fields to the corresponding initial values? If you think
> that's
Ok, thanks for your reply, I'll try to submit a patch with an original
exception stored as soon as I figure out how to do that.
On Dec 2, 10:30 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2007-12-02 at 12:17 -0800, mezhaka wrote:
> > I have an assertion statement in my urls.py. Wh
Travis Terry wrote:
> 4. P2's get_or_create() tries to create the item. One of two things
> happens:
> a. a second item is created with the same parameters if this doesn't
> violate a UNIQUE constraint
> b. the second create fails (because of a UNIQUE constraint) and
> raises an except
On 4 Dec 2007, at 13:26, bobj wrote:
> Simon - These are GREAT!!! Ideas. The regular expression based URL
> dispatching replacement has been something I personally have been
> thinking about for some time. I would be interested in helping with
> this If you put together a proposal. One URL imp
Titus Brown, the author of twill, fixed this issue in the latest
snapshot. It's available from
http://darcs.idyll.org/~t/projects/twill-latest.tar.gz
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers
On Dec 3, 2007 4:34 PM, akaihola <[EMAIL PROTECTED]> wrote:
>
> I tried old versions of twill, and it seemed to work correctly in
> 0.8.4, but version 0.8.5 introduced this duplicating behavior. I can
> see that the application result reading mechanism was heavily modified
> at that point.
Hello.
Ivan Sagalaev wrote:
>
> Actually there is a common solution to this problem that doesn't create
> duplicates and doesn't fail on second transaction. And as James
> correctly has noted it works on database level. The solution is a form
> of SELECT called SELECT FOR UPDATE. When one transaction
Travis Terry wrote:
> It's my understanding that SELECT ... FOR UPDATE only locks the rows
> that it reads (so you can be sure they can be updated or referenced
> later in the same trasaction). However, in the case of get_or_create(),
> there is no existing row
Oh... Indeed. Then this won't h
2007/12/4, Karen Tracey <[EMAIL PROTECTED]>:
> Anyone want to register an opinion on how deep in the hierarchy this should
> go? Seems to me it could be generally useful for BaseForm to be able to
> report what fields' cleaned values are different from what was specified as
> initial data.
+1 fr
On Mon, 2007-12-03 at 16:02 -0800, SmileyChris wrote:
> On Dec 4, 4:39 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > > lazy()
> >
> > Of course it works. We're using it throughout Django for lazy
> > translations.
>
> It only just works :P
it's called Fit For Purpose. You've yet to de
Slicing is cool, but I'm +1 for deprecating it and using .limit().
Slicing in my mind should return an iterable and you shouldn't be
messing w/ properties on that iterable, even though somethings you
might want to.
For example:
We extend the queryset model for our fulltext search -- which uses
s
I would like to see a replacement for the regex scheme as well, but not
because I am uncomfortable with regexes. I think the typical regex for
a URL is noisy: it's hard to see the intent of the expression. Most URL
regexes follow some very well-defined patterns, and we don't have a way
to exp
On 12/4/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> I don't have a suggestion for a replacement, and I don't think it needs to
> be on the 1.0 list (since it can be added without breaking backward
> compatibility), but I think it would be a big plus.
While I actually like the power and flexi
On Dec 4, 2007 10:31 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 12/4/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> > I don't have a suggestion for a replacement, and I don't think it needs to
> > be on the 1.0 list (since it can be added without breaking backward
> > compatibility), bu
On Dec 4, 2007 10:17 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> Selector[1], a raw WSGI middleware for url dispatching, uses something
> almost exactly like this. Although, there are a few things we
> obviously wouldn't want, it provides a decent starting point. I'd
> suggest ignoring all the
On Dec 5, 2:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> > It only just works :P
>
> it's called Fit For Purpose. You've yet to demonstrate somewhere in
> Django we need all these extra levers of which you speak.
The lazy __proxy__ class is full of magical bits, which I don't really
get
On Tue, 2007-12-04 at 20:47 -0800, SmileyChris wrote:
> On Dec 5, 2:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > > It only just works :P
> >
> > it's called Fit For Purpose. You've yet to demonstrate somewhere in
> > Django we need all these extra levers of which you speak.
>
> The
Luke Plant wrote:
> On Tuesday 04 December 2007 07:25:31 Gary Wilson wrote:
>
>> Sort of my point. Since filter() and [:] both return QuerySets why
>> should they be any different:
>>
>> UTPerson.objects.all().filter(name__startswith='a')[:10]
>
> 1) This, logically, should return the first ten
Adrian Holovaty wrote:
> On Dec 4, 2007 12:57 AM, Gary Wilson <[EMAIL PROTECTED]> wrote:
>> But what would the situation be with a new limit() method...
>>
>> objects = MyModel.objects.filter(site=1)
>> first_one = objects.limit(1)
>> do_something_special(first_one)
>> return render_to_response('t
I've attached a patch that does the following:
* Added a `handle_response` method to `BaseHandler` to factor out duplicated
code in `ModPythonHandler`, `WSGIHandler`, and `ClientHandler`.
* Replaced `resolver` temporary variable with a `resolver` method to ease
refactoring of `get_response` met
46 matches
Mail list logo
