SEE INDIAN SEXY VIEDO AND PICS
http://chromoo.blogspot.com/
--~--~-~--~~~---~--~~
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@googlegroups.com
To
On 10/11/07, David Reynolds <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've just added this ticket (#5737), which I am quite keen to fix, as
> it would be useful for the project I'm currently working on, can
> anyone give me any advice as to whether this is something that can be
> fixed and where I
On Oct 11, 12:03 pm, Karen Tracey <[EMAIL PROTECTED]> wrote:
> At 06:00 PM 10/10/2007, Joseph Kocherhans wrote:
>
>
>
> > > >You're probably right. Something like radio_admin_fields on the
> > > >ModelAdmin class sounds reasonable. Could you file a ticket for this
> > > >so we don't lose
On 2007-10-11 17:10:30 -0600, jf
<[EMAIL PROTECTED]> said:
>
> Hi all, I am currently using Django on a project with a database of
> fairly large table sizes, and I have encountered a strange and
> potentially dangerous bug, of which I am not sure the cause. This is
> not really a bug report,
At 06:00 PM 10/10/2007, Joseph Kocherhans wrote:
> > >You're probably right. Something like radio_admin_fields on the
> > >ModelAdmin class sounds reasonable. Could you file a ticket for this
> > >so we don't lose track? I don't recall seeing one, but I could be
> > >wrong.
> >
> > I couldn't
Just to ping this again (since I think it's super-convenient and don't
want it to get lost), I've created ticket 5741 with a patch and doc
changes. The patch would look the same for the queryset-refactor
branch as it stands now, too.
http://code.djangoproject.com/ticket/5741
Dan
On Aug 23,
I am working on a db/backend/odbc module using cdODBC. Can someone review the
mapping I came up with? I #ed the ones that didn't seem to have any that fit.
description of the datatypes: http://ceodbc.sourceforge.net/html/vartypes.html
# Maps type objects to Django Field types.
Hi,
I've just added this ticket (#5737), which I am quite keen to fix, as
it would be useful for the project I'm currently working on, can
anyone give me any advice as to whether this is something that can be
fixed and where I should look to fix it?
Thanks,
David
On 10/11/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 10/8/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> > Should I follow up on this with the Python mailing list, or will you?
>
> I'd love it if you could - thanks!
OK, I quickly dug through the mailing list archives to see which one
On 10/10/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> The final result would be that the exception clauses in Django would
> be a method, reducing the exception clause in the base handler to
> calling that method.
[...]
> I think this keeps the exception handling semantics the same, but
>
On 10/8/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> Should I follow up on this with the Python mailing list, or will you?
I'd love it if you could - thanks!
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On Thu, 2007-10-11 at 06:47 -0700, Tai Lee wrote:
> ForeignKey with unique=True does work and is the same at the SQL
> level, but OneToOneField does have a couple of niceties attached to it
> like adding the related object as an attribute to the model containing
> the OneToOneField. If those
Hello Malcolm,
On Oct 11, 4:20 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
>
> ForeignKey(unique=True)
>
I will try it this way & hope it works exactly as I need it to.
Thank you for reading carefully my Email :-)
My main point was not to criticize Django but to understand if there
are
ForeignKey with unique=True does work and is the same at the SQL
level, but OneToOneField does have a couple of niceties attached to it
like adding the related object as an attribute to the model containing
the OneToOneField. If those could be re-added to ForeignKey fields
with unique=True, that
Hello Marty,
On Oct 11, 4:09 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> Also, for what it's worth, it's quite a leap to go from "one-to-one
> relationships have problems" to "Django is not made to the purpose of
> code reuse".
> There are many ways to reuse code in Django, without
> having
On Wed, 2007-10-10 at 22:12 -0700, [EMAIL PROTECTED] wrote:
> Hello,
>
> I am following the discussion in the ticket
> http://code.djangoproject.com/ticket/2145,
> and I think its not correct place to discuss theoretical things in
> ticket, instead discussion should be moved to a Groups (to
Also, for what it's worth, it's quite a leap to go from "one-to-one
relationships have problems" to "Django is not made to the purpose of
code reuse". There are many ways to reuse code in Django, without
having anything to do with one-to-one relationships, or even model
relationships at all.
On Thu, 2007-10-11 at 02:18 -0700, Ilya Semenov wrote:
> I'm one of those who participated in ticket #2145 discussion. I must
> admit you have the most sane and comprehensive opinion I ever heard on
> the 1-to-1 problem. Completely agreed on the every point.. And no, I
> don't see any other way
I don't know a whole lot about exception handling in middleware yet,
but I like the idea of making it easier to inject more functionality
into the default handler. For instance, I like the postmortem for
template loader errors, but I've also wished I could include something
like that for my own
I'm one of those who participated in ticket #2145 discussion. I must
admit you have the most sane and comprehensive opinion I ever heard on
the 1-to-1 problem. Completely agreed on the every point.. And no, I
don't see any other way on practically extending the models for
natural and DRYish
20 matches
Mail list logo
