SmileyChris wrote:
> On Aug 30, 11:47 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>> On Thu, 2007-08-30 at 19:01 +0800, Russell Keith-Magee wrote:
>>> On 8/30/07, SmileyChris <[EMAIL PROTECTED]> wrote:
It has always made me wonder why it isn't even overridable. Is there a
design
On 8/31/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I'm *way* to busy to work on this myself, but I wanted to chime in and
> give a big, fat +1 -- Django on Jython would be a *big* win for people
> looking to use Django in Enterprisy situations.
My thoughts exactly. It's something I'll def
It should probably be 320, and if there are any databases that don't
support a field that long, it should be reduced to accomodate those
databases (only), rather than holding everything back for the lowest
common denominator?
--~--~-~--~~~---~--~~
You received thi
> If there are any, then I would expect it'd handle them just as it does
> without the flag. The problem is (at least in my eyes) that Django
> should not be guessing, and especially should not be doing an extra
> query, when you are explicitly saing update or create on an object.
Django *would*
On Thu, 2007-08-30 at 21:18 +0800, Russell Keith-Magee wrote:
> Hi all,
>
> I've been looking at ticket #4412:
>
> http://code.djangoproject.com/ticket/4412
>
> This ticket adds support for optgroups in selects for newforms. I've
> uploaded an updated patch that works with trunk and newforms-ad
Hi folks --
I'm *way* to busy to work on this myself, but I wanted to chime in and
give a big, fat +1 -- Django on Jython would be a *big* win for people
looking to use Django in Enterprisy situations.
If there are bits of Django that need to be fixed for Jython support,
please file tickets with
On 8/31/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Given that we're duplicating some effort here, I wonder if we could
> set up an SVN repository somewhere to work on this together? It'd be
> just another Django branch, but the official policy is to set up our
> own SVN to work on it. I don't
Marty Alchin wrote:
> On 8/31/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
>>> I won't pretend to have tested everything, but it looks like Django on
>>> Jython (Jango? Djython?)
>> Jyngo? [Not a native speaker, so I really don't know which sounds better]
>
> Sorry, I wasn't very clear that I was j
On 8/31/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > I won't pretend to have tested everything, but it looks like Django on
> > Jython (Jango? Djython?)
>
> Jyngo? [Not a native speaker, so I really don't know which sounds better]
Sorry, I wasn't very clear that I was joking. I wouldn't really
On 8/31/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> I won't pretend to have tested everything, but it looks like Django on
> Jython (Jango? Djython?)
Jyngo? [Not a native speaker, so I really don't know which sounds better]
> should work fairly well once it has a
> database backend and a req
Thanks James.
I opened the thread on the django-users list.
On Aug 31, 11:57 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 8/31/07, Sebastian Macias <[EMAIL PROTECTED]> wrote:
>
> > What I'm concerned about is that Article.objects.all() will return a
> > query_set with all of the records.
I'm building an app that requires pagination. I looked at the official
pagination documentation I found at:
http://www.djangoproject.com/documentation/models/pagination/
I followed the tutorial and basically: paginator =
ObjectPaginator(Article.objects.all(), 5) is where all the "magic"
happens.
I won't pretend to have tested everything, but it looks like Django on
Jython (Jango? Djython?) should work fairly well once it has a
database backend and a request handler. I have no idea how much it
would take to write a db backend using zxJDBC, but the request handler
should be fairly straightf
If there are any, then I would expect it'd handle them just as it does
without the flag. The problem is (at least in my eyes) that Django
should not be guessing, and especially should not be doing an extra
query, when you are explicitly saing update or create on an object.
On Aug 31, 2:24 am, "Vs
On 8/31/07, jorjun <[EMAIL PROTECTED]> wrote:
>
> Glad though I am that Python has dynamic class attributes, when it
> comes to Django Models, some more discipline could be useful,
> especially when a product is in maintenance phase, IMO.
>
> I recently added the code below to my model definition
Glad though I am that Python has dynamic class attributes, when it
comes to Django Models, some more discipline could be useful,
especially when a product is in maintenance phase, IMO.
I recently added the code below to my model definition and it saved me
a bunch of time after some model evolutio
On 8/31/07, Nicola Larosa <[EMAIL PROTECTED]> wrote:
>
> > we should either fix the current admin (depending on
> > how long it'll take newforms-admin to land), to work out what's going
> > wrong so we don't have the same problem in newforms-admin (..and there
> > are a few tickets open requesting
2007/8/31, David Cramer <[EMAIL PROTECTED]>:
>
> We were talking it over in IRC, and here's a pretty good solution:
>
> Intially is_stored is set to None. When you do a .get or .create it
> would then set it to True. When you delete, it would set to False.
>
> A big that this does solve, beyond fi
On Aug 31, 2:39 am, David Cramer <[EMAIL PROTECTED]> wrote:
> Intially is_stored is set to None. When you do a .get or .create it
> would then set it to True. When you delete, it would set to False.
>
> A big that this does solve, beyond fixing my multiple pks, is explicit
> calls.
>
> - Calling .
On 8/31/07, ludvig.ericson <[EMAIL PROTECTED]> wrote:
> > - Calling .create would no longer do a select + insert (or update) if
> > you had a pk attribute set.
> > - Calling .create would error if the row already exists.
>
> Am I the only one seeing concurrency issues everywhere in this thread?
Simon Greenhill wrote:
> If anyone's looking for something to do over the weekend [1], there
> seems to be one whole metric tonne of issues caused by people trying
> to use edit_inline and unique_together at the same time in the admin
> section.
Yeah, it's the very first I stumbled into, when mod
21 matches
Mail list logo
