M2M Column Names Changed in 1.2 - Breaks Backwards Compatibility

[simonb]

I think this ticket http://code.djangoproject.com/ticket/12386
identifies a change in the m2m code which breaks backwards
compatibility.

Consider the following three apps and models:

AppA/models.py:

class ModelA(models.Model):
name = models.CharField(max_length=1024, default='', blank=True)

AppB/models.py:

class ModelB(models.Model):
name = models.CharField(max_length=1024, default='', blank=True)
ma = models.ManyToManyField('AppA.ModelA', blank=True, null=True,
related_name='mb')
mc = models.ManyToManyField('AppC.ModelC', blank=True, null=True,
related_name='mc')

AppC/models.py:

class ModelC(models.Model):
name = models.CharField(max_length=1024, default='', blank=True)

The SQL generated for the m2m fields in AppB is different for Django
1.1 and 1.2/trunk. This breaks backwards compatibility.

It seems that in some cases 1.2 names the m2m column 'app.model_id'
whereas 1.1 uses 'model_id' only - i.e. no 'app.'

This only seems to happen when there are more that one m2m fields in a
model. Tested with postgresql. The SQL output for the M2M table is
show below for the different Django versions.

Django 1.1

CREATE TABLE "AppB_modelb_mc" (
"id" serial NOT NULL PRIMARY KEY,
"modelb_id" integer NOT NULL REFERENCES "AppB_modelb" ("id")
DEFERRABLE INITIALLY DEFERRED,
"modelc_id" integer NOT NULL REFERENCES "AppC_modelc" ("id")
DEFERRABLE INITIALLY DEFERRED,
UNIQUE ("modelb_id", "modelc_id")
);

Django 1.2

CREATE TABLE "AppB_modelb_mc" (
"id" serial NOT NULL PRIMARY KEY,
"modelb_id" integer NOT NULL,
"appc.modelc_id" integer NOT NULL,
UNIQUE ("modelb_id", "appc.modelc_id")
);

1.1 = "modelc_id"
1.2 = "appc.modelc_id"

I've uploaded a little test project to the ticket which demonstrates.

Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Porting Django to Python 3

[VernonCole]

Having survived the update of pywin32 to python 3, let me say that
both comments are correct:
1) you do NOT create a fork, you convert the existing code so that it
will run through 2to3
2) it takes a LOT of hand refactoring of older 2.x code to get ready
for 2to3.
and, may I add:
3) it's worth the work.  The refactoring tends to clean up rough edges
that have been hanging around the old code from long, long ago.
IMHO it is absolutely necessary for one or more core developers to be
intimately involved with the conversion. Such things as conversion to
new style classes and byte buffer creation objects will very likely
reach into a majority of the existing modules, so the volume of
patches will be very large.  If these patches are not integrated into
the tip branch(es) rapidly, it is likely that new work will get very
confusing.  I personally found it very helpful to incorporate
suggestions from the guys doing the 2-to-3 conversion directly into
the development branch I was working on -- so that within a day my
development branch became the 2-to-3 conversion branch as well.  By
the time I finished my next incremental update, it was 2to3 ready.

Cheering from the sidelines is not enough.

  By the way, the pywin32 modules work in all versions of Python from
2.3 to 3.1 (mine works in IronPython as well.) 2.6 is helpful for a
conversion effort, but not necessary.
--
Vernon Cole


On Jan 13, 7:22 am, Karen Tracey  wrote:
> On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa  wrote:
> > 2010/1/13 Tobias McNulty :
> > > I am by no means an expert on the matter, but I remember seeing a comment
> > > awhile back suggesting that it generally makes more sense to fix the 2to3
> > > script than to maintain two branches of the same library. Might that be
> > the
> > > case here as well?
>
> > Py3K does not support old-style classes. Django uses these quite a
> > lot, for instance the Meta-class of a model is old-style. I don't
> > think it is in any way possible to have an automatic script convert
> > these in a sensible way as django is deliberately utilizing the
> > difference between old and new style in no doubt a django-specific
> > way. If django on 2.x could be rewritten to no longer depend on
> > old-style classes, and was made to depend on python 2.6 or newer, then
> > 2to3 would have a chance to do its magic.
>
> I'm no expert either, but as I understanding it maintaining single source
> for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the
> 3.x version during install may be a viable option.  This is the approach
> that was taken by Martin v. Löwis when he got an initial port working back
> in late 2008:
>
> http://wiki.python.org/moin/PortingDjangoTo3k
>
> He cites bugs in 2to3 as a barrier to getting the approach to work at that
> time, but doesn't note anything insurmountable he ran across in the Django
> source.  It is true the port only verified that getting through the tutorial
> worked, but that covers the basics of models certainly.
>
> Karen
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Logging format decision

[Russell Keith-Magee]

On Sun, Jan 10, 2010 at 4:45 AM, Ivan Sagalaev
 wrote:
> Hello everyone!
>
> There was a discussion here some time ago about logging in Django that led
> to the ticket 12012 [1] where Simon has done most (all?) of the
> implementation.
>
> There is still a disagreement on the format of the configuration dict for
> it. Simon has implemented it from my ad-hoc proposal [2]. Vinay Sajip has an
> alternative suggestion [3]. I think a core-dev ruling is due here.

Hi Ivan,

Sorry for taking so long to reply to this. Logging was on my todo list
for 1.2, but unfortunately, I didn't have enough time to drive the
logging proposal as well as the other features that I wanted to get
into 1.2.

Now that the alpha is out, the major feature freeze is in place, so
the opportunity for logging in 1.2 has passed. Although logging isn't
especially complicated in itself, we need to do it right. I don't want
to rush anything into trunk just so I can tick a box on a feature
list.

That said - I really do want to see logging in Django's trunk. If we
can sort out the details in the background and get a good
implementation ready, it could easily be the first feature committed
for v1.3.

> To state my own opinion, I sill like my format better because it defines
> each logging channel in one place without needing to separately define
> formatters and handlers. I understand that it makes it less powerful but I'd
> rather have a very simple format here -- we still can configure logging
> imperatively in advanced cases.

I like Vinay's suggestion for exactly the reason you dislike it. The
definition of a handler is independent of the loggers that use that
handler. Simon's example in (4) hides a lot of details behind ellipses
- if you expand those ellipses, you discover that there is a lot of
repeated typing of '/tmp/django-sql.log' etc if you want all your logs
to appear in the same file. Under Vinay's proposal, you define a
single file log handler, and instruct each of the loggers to use that
handler.

The other reason to like Vinay's format is that this is the format
he's trying to push into Python trunk. If Python is going to adopt a
configuration format, it makes sense that we should adhere to it. The
last thing we need is another NIH argument getting leveled at Django
by the wider Python community :-)

The other issue that I think still needs to be addressed is the
internal usage of logging by Django itself. The last time I looked at
it, Simon's branch provided the plumbing to support logging, but
didn't really make extensive use of that plumbing. In particular, the
logging framework should be able to supplement/replace anywhere that
mail_admins is currently being used, so that the current 'send an
email' error notification process can be configured to 'log the error
AND send an email' or 'just log the error'. If you want to help
advance this ticket, updating the patch to demonstrate how Django will
use logs internally will be an important step.

Yours,
Russ Magee %-)
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Porting Django to Python 3

[Karen Tracey]

On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa  wrote:

> 2010/1/13 Tobias McNulty :
> > I am by no means an expert on the matter, but I remember seeing a comment
> > awhile back suggesting that it generally makes more sense to fix the 2to3
> > script than to maintain two branches of the same library. Might that be
> the
> > case here as well?
>
> Py3K does not support old-style classes. Django uses these quite a
> lot, for instance the Meta-class of a model is old-style. I don't
> think it is in any way possible to have an automatic script convert
> these in a sensible way as django is deliberately utilizing the
> difference between old and new style in no doubt a django-specific
> way. If django on 2.x could be rewritten to no longer depend on
> old-style classes, and was made to depend on python 2.6 or newer, then
> 2to3 would have a chance to do its magic.
>
>
I'm no expert either, but as I understanding it maintaining single source
for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the
3.x version during install may be a viable option.  This is the approach
that was taken by Martin v. Löwis when he got an initial port working back
in late 2008:

http://wiki.python.org/moin/PortingDjangoTo3k

He cites bugs in 2to3 as a barrier to getting the approach to work at that
time, but doesn't note anything insurmountable he ran across in the Django
source.  It is true the port only verified that getting through the tutorial
worked, but that covers the basics of models certainly.

Karen
-- 

You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to django-develop...@googlegroups.com.

To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Porting Django to Python 3

[Russell Keith-Magee]

On Wed, Jan 13, 2010 at 5:21 PM, Hanne Moa  wrote:
> 2010/1/13 Tobias McNulty :
>> I am by no means an expert on the matter, but I remember seeing a comment
>> awhile back suggesting that it generally makes more sense to fix the 2to3
>> script than to maintain two branches of the same library. Might that be the
>> case here as well?
>
> Py3K does not support old-style classes. Django uses these quite a
> lot, for instance the Meta-class of a model is old-style. I don't
> think it is in any way possible to have an automatic script convert
> these in a sensible way as django is deliberately utilizing the
> difference between old and new style in no doubt a django-specific
> way. If django on 2.x could be rewritten to no longer depend on
> old-style classes, and was made to depend on python 2.6 or newer, then
> 2to3 would have a chance to do its magic.

I can't think of any case where Django *requires* old-style classes.
Old-style classes are certainly used, but that's a combination of
accident, historical implementation and a small dose of clean API
styling ("class Meta" is cleaner and clearer than "class
Meta(object)"). I can't think of any reason why Django's current usage
of old-style classes couldn't be migrated to new-style classes.

Yours,
Russ Magee %-)
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Porting Django to Python 3

[Hanne Moa]

2010/1/13 Tobias McNulty :
> I am by no means an expert on the matter, but I remember seeing a comment
> awhile back suggesting that it generally makes more sense to fix the 2to3
> script than to maintain two branches of the same library. Might that be the
> case here as well?

Py3K does not support old-style classes. Django uses these quite a
lot, for instance the Meta-class of a model is old-style. I don't
think it is in any way possible to have an automatic script convert
these in a sensible way as django is deliberately utilizing the
difference between old and new style in no doubt a django-specific
way. If django on 2.x could be rewritten to no longer depend on
old-style classes, and was made to depend on python 2.6 or newer, then
2to3 would have a chance to do its magic.


HM
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.