Hi,
I get the following stacktrace after updating trunk (to post-unicode-
branch-merge)
I am posting this here, because I don't see any of my views involved
in the stacktrace and I have a hard time figuring out what is wrong
(having followed all the steps here
On Fri 13 Jul 2007, Todd O'Bryan wrote:
> On Thu, 2007-07-12 at 15:40 -0500, Adrian Holovaty wrote:
> > On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > > Is there a good reason not to do something like the following in
> > > django.db.models.Model?
> > >
> > > def form(self):
> > >
2007/6/23, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
>
> As always, criticism, ideas and suggestions are welcome!
>
Ok let's go :-)
First of all, thanks for your awesome work, I eventually take time to
review it and it sounds exactly what I expected. Here are some random
thoughts about the
> By the way, this is probably a more appropriate thread for django-users,
> since it's not really involved with the development of Django itself. I
> wasn't concentrating when I hit reply.
ups, my bad, but thanks for the answer anyway! I will look at the
things you pointed out
On Fri, 2007-07-13 at 02:21 -0700, Johan Bergström wrote:
> Why not put simplejson as a depedency in setup.py, so easy_install
> fetches the latest avaliable version instead of the possibly older
> bundled version then?
> I get the point, as simplejson is a very integrated part in core
>
Why not put simplejson as a depedency in setup.py, so easy_install
fetches the latest avaliable version instead of the possibly older
bundled version then?
I get the point, as simplejson is a very integrated part in core
functionality. It is still a third party though and the 'requirement'
can be
On Fri, 2007-07-13 at 00:48 -0700, frank h. wrote:
> Hi,
> I get the following stacktrace after updating trunk (to post-unicode-
> branch-merge)
> I am posting this here, because I don't see any of my views involved
> in the stacktrace and I have a hard time figuring out what is wrong
> (having
On Fri, 2007-07-13 at 00:48 -0700, frank h. wrote:
> Hi,
> I get the following stacktrace after updating trunk (to post-unicode-
> branch-merge)
> I am posting this here, because I don't see any of my views involved
> in the stacktrace and I have a hard time figuring out what is wrong
> (having
I have released a package called django_options on the Cheeseshop at
http://cheeseshop.python.org/pypi/django_options/r6
It is a class called MetaOptions that enables decoration of Django models
with meta classes in similar style to Admin and Meta. Options placed
there show up in
Am 11.07.2007 um 07:49 schrieb [EMAIL PROTECTED]:
> I welcome any and all help!!! I don't see this as anything crucial or
> time sensitive.
> For my part I want this feature for a project, and at worst can
> include the code as an app there. I just believe it should be part of
> the django
On 7/13/07, koenb <[EMAIL PROTECTED]> wrote:
> Maybe I am missing something here.
Nah -- not really; I understand (and agree with) your objections.
We're just gonna give this different method a try for a time and see
how it works out.
Jacob
--~--~-~--~~~---~--~~
On 11 jul, 16:12, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 7/11/07, Ben Ford <[EMAIL PROTECTED]> wrote:
>
> > None as yet, I'm really keen to get it back into the svn repo, but I think
> > the people concerned are busy with other things at the moment.
>
> I've said this a couple
> I was, however, turned off by the state of pydb2 -- it looked like the
> project hasn't been touched in years.
You are right. I used the patch made by Javier Villavicencio (see
[1]), which makes things somewhat better.
I contacted him, and it seems he has a lot more improvements ready,
but
Hi Russell,
Thanks for responding to this thread. You were right
for the data not matching the model. The assumption that
some_model_instance.__dict__.keys() would return the fields names
is simply wrong. :)
Yes im trying to get a csv deserializer using the python.py and
csv.py modules as a
Added a few tests and docs - not sure how good they are, but better
than nothing :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On Jul 13, 10:54 am, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> Um, you do realize that you don't normally need any kind of
> hyphenation in web applications?
All depends on what you mean by 'web applications'.
This is defiantly a good feature for mobile devices. Also there are
many filters
I'd like to add a QuerySet.exists() method, which would return True or
False if the given QuerySet contains at least one record. This would
be more efficient than qs.count() or len(qs) because it would perform
the following SQL under the hood:
SELECT 1 FROM [table] WHERE [where] LIMIT 1;
On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> I'd like to add a QuerySet.exists() method, which would return True or
> False if the given QuerySet contains at least one record. This would
> be more efficient than qs.count() or len(qs) because it would perform
> the following SQL
On 7/13/07, Tom Tobin <[EMAIL PROTECTED]> wrote:
> +0; seems like a reasonable addition. I wonder of "any" might be a
> better method name (along the lines of the Python 2.5 built-in
> function), but either name would be fine IMHO.
Err, I wonder *if*. ::sigh:: :-)
On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> I'd like to add a QuerySet.exists() method, which would return True or
> False if the given QuerySet contains at least one record. This would
> be more efficient than qs.count() or len(qs) because it would perform
> the following SQL
Adrian Holovaty wrote:
> I'd like to add a QuerySet.exists() method, which would return True or
> False if the given QuerySet contains at least one record. This would
> be more efficient than qs.count() or len(qs) because it would perform
> the following SQL under the hood:
>
> SELECT 1 FROM
On Jul 14, 9:55 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Adrian Holovaty wrote:
> > I'd like to add a QuerySet.exists() method, which would return True or
> > False if the given QuerySet contains at least one record. This would
> > be more efficient than qs.count() or len(qs) because it
On 7/13/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> Adrian, I think it's useful enough. But why do you need a .exists() if
> we could just use __nonzero__ (like Ivan suggested)?
I hadn't thought of that! Yes, we should definitely implement a
QuerySet.__nonzero__() method. However, I'd like
On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Yes, we should definitely implement a
> QuerySet.__nonzero__() method. However, I'd like there to be an
> explicit method (named either exists() or any() or whatever), because
[snip]
Agreed -- I'm +0 on .exists() and __nonzero__() being an
On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> On 7/13/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> > Adrian, I think it's useful enough. But why do you need a .exists() if
> > we could just use __nonzero__ (like Ivan suggested)?
>
> I hadn't thought of that! Yes, we should definitely
On 7/11/07, koenb <[EMAIL PROTECTED]> wrote:
>
> I am trying to create a django backend for DB2. I am trying to do this
> using a DB2 Express C and the pydb2 module.
>
> It is coming around quite nicely. I have the test suite down to 7
> failures and 3 errors, but now I am a bit stuck.
>
Nice!
+1 on both. I was needing this just the other day.
Michael
On 7/13/07, Brian Harring <[EMAIL PROTECTED]> wrote:
>
> On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > On 7/13/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> > > Adrian, I think it's useful enough. But why do you need a
On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I'm biased, because I have an immediate need for this in a project,
> but this seems general and useful enough for inclusion in QuerySet.
Implementing the check in __nonzero__ and having people test by doing
'if some_queryset' or 'if not
On Fri, 2007-07-13 at 16:22 -0500, Adrian Holovaty wrote:
> I'd like to add a QuerySet.exists() method, which would return True or
> False if the given QuerySet contains at least one record. This would
> be more efficient than qs.count() or len(qs) because it would perform
> the following SQL
> By the way, for all database backends except SQLite, you can implement
> all of this sort of stuff (including exists and __len__) fairly fast
> using cursor.rowcount (the number of rows in the result set).
> Unfortunately, SQLite always returns -1 for rowcount. I'm building a few
> of those
On 7/12/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> A few comments (mostly questions) from an initial reading:
I've now implemented most of your suggestions [1]; a few questions
remain, though:
1) If I'm going to import the taghelpers errors/API into
django.template, I'll need to in
On Fri, 2007-07-13 at 21:56 -0600, Ian Kelly wrote:
> > By the way, for all database backends except SQLite, you can implement
> > all of this sort of stuff (including exists and __len__) fairly fast
> > using cursor.rowcount (the number of rows in the result set).
> > Unfortunately, SQLite
Brian Harring wrote:
> On Wed, Jul 11, 2007 at 09:38:54AM -0500, Deryck Hodge wrote:
>> For example:
>>
>> mkdir repos
>> cd repos
>> bzr init
>> svn co http://code.djangoproject.com/svn/django/trunk/ django_trunk
>> bzr add django_trunk
>> bzr commit
>>
>> Then you can bzr branch from there to
On 7/13/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
[...]
> Due to Oracle inclusion, this has to be
>
> select count(*) from [table] where [...]
>
> and then check that the result is > 0, at least in the Oracle backend
> (no "limit" extension in Oracle). The problem being that
James Bennett wrote:
> On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>> I'm biased, because I have an immediate need for this in a project,
>> but this seems general and useful enough for inclusion in QuerySet.
>
> Implementing the check in __nonzero__ and having people test by doing
>
35 matches
Mail list logo
