ManyToManyField looks broken
I'd like to draw some attention to ticket http://code.djangoproject.com/ticket/2232 (mainly russelm's attention as it appeared after his checkin 3195). Basically ManyToMany relations don't work when you try to get related queryset from a model where ManyToManyField is defined. Or is it just me? --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
On Sun, 2006-06-25 at 14:04 +0400, Ivan Sagalaev wrote: > I'd like to draw some attention to ticket > http://code.djangoproject.com/ticket/2232 (mainly russelm's attention as > it appeared after his checkin 3195). > > Basically ManyToMany relations don't work when you try to get related > queryset from a model where ManyToManyField is defined. Or is it just me? Pretty much "just you", but it's obviously a little trickier than that. This is basically ticket #1796 occurring again. You'll find it will only fail in some very specific cases and it's dependent upon both your machine and your Python build. The patch labelled ManyToMany.patch in ticket #1796 might well fix your problem in the short-term. I tend to agree with Luke (see his last comment on that ticket) that it's probably the completely correct fix, rather a correction after the fact of the problem. But we might have to check it in for now until we work out the deeper mystery there (which could well just be that things imported from different paths cannot be identified with each other reliably and so we can't fix this). Are the tests failing for you, too, Ivan? I just ran them (and my code is up to date) and also tested out a few apps I have here using ManyToMany and I saw no problem. I'm looking at #1796 now. Will try to check in something reasonable if I can in the next couple of hours (although I can't actually replicate the problem, so I'll probably just have to Use The Force or something). Regards, Malcolm --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
On Sun, 2006-06-25 at 20:20 +1000, Malcolm Tredinnick wrote: > On Sun, 2006-06-25 at 14:04 +0400, Ivan Sagalaev wrote: > > I'd like to draw some attention to ticket > > http://code.djangoproject.com/ticket/2232 (mainly russelm's attention as > > it appeared after his checkin 3195). > > > > Basically ManyToMany relations don't work when you try to get related > > queryset from a model where ManyToManyField is defined. Or is it just me? > > Pretty much "just you", but it's obviously a little trickier than that. > This is basically ticket #1796 occurring again. You'll find it will only > fail in some very specific cases and it's dependent upon both your > machine and your Python build. > > The patch labelled ManyToMany.patch in ticket #1796 might well fix your > problem in the short-term. I tend to agree with Luke (see his last > comment on that ticket) that it's probably the completely correct fix, ".. probably NOT the completely correct fix." Oh dear, an unfortunate typo. > rather a correction after the fact of the problem. But we might have to > check it in for now until we work out the deeper mystery there (which > could well just be that things imported from different paths cannot be > identified with each other reliably and so we can't fix this). > > Are the tests failing for you, too, Ivan? I just ran them (and my code > is up to date) and also tested out a few apps I have here using > ManyToMany and I saw no problem. > > I'm looking at #1796 now. Will try to check in something reasonable if I > can in the next couple of hours (although I can't actually replicate the > problem, so I'll probably just have to Use The Force or something). Malcolm --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
Malcolm Tredinnick wrote: > Pretty much "just you", but it's obviously a little trickier than that. > This is basically ticket #1796 occurring again. I've dug a bit further and have found out that mentioned changeset (3195) has broken only certain relations (for cross-app models and another case I have described in the ticket 2232) > You'll find it will only > fail in some very specific cases and it's dependent upon both your > machine and your Python build. I see the problem in this bug too (just created a very minimal test app with two models). It looks like it's not related to the new ticket since it fails both before and after changeset 3195. > Are the tests failing for you, too, Ivan? No, tests are Ok (except some failures in default filters that I have patched locally, but it's not related... hopefully :-) ). --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Error when iexact meets integer field.
Thanks for helping :-) --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
On 6/25/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > I'd like to draw some attention to ticket > http://code.djangoproject.com/ticket/2232 (mainly russelm's attention as > it appeared after his checkin 3195). Paying attention now :-) > Basically ManyToMany relations don't work when you try to get related > queryset from a model where ManyToManyField is defined. Or is it just me? For me, all the regression tests passed at time of checkin. Following the rest of the messages on this thread, it looks like the problems is with model importing. 2 quick observations which might help find the problem: 1) r3195 did make some changes to the model importing process, so this might have changed the conditions under when any previous __import__ related bug revealed itself 2) I have seen the behaviour from r1796 before - for me, the problem ultimately turned out to be caused by a PYTHONPATH that included the application directory (so "from myapp.models import Foo" and "from myproject.myapp.models import Foo" were both legal). At the time, I chalked it up to the pythonpath, and moved on (sorry - can't give any more specific details as to SVN revision, exact code structure, etc). I don't know if this helps anyone - however, I thought it might yield a reliably broken test case. Russ %-) --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
On Sun, 2006-06-25 at 22:39 +0800, Russell Keith-Magee wrote: > On 6/25/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > > > I'd like to draw some attention to ticket > > http://code.djangoproject.com/ticket/2232 (mainly russelm's attention as > > it appeared after his checkin 3195). > > Paying attention now :-) > > > Basically ManyToMany relations don't work when you try to get related > > queryset from a model where ManyToManyField is defined. Or is it just me? > > For me, all the regression tests passed at time of checkin. Following > the rest of the messages on this thread, it looks like the problems is > with model importing. 2 quick observations which might help find the > problem: > > 1) r3195 did make some changes to the model importing process, so this > might have changed the conditions under when any previous __import__ > related bug revealed itself > > 2) I have seen the behaviour from r1796 before - for me, the problem > ultimately turned out to be caused by a PYTHONPATH that included the > application directory (so "from myapp.models import Foo" and "from > myproject.myapp.models import Foo" were both legal). At the time, I > chalked it up to the pythonpath, and moved on (sorry - can't give any > more specific details as to SVN revision, exact code structure, etc). > > I don't know if this helps anyone - however, I thought it might yield > a reliably broken test case. I've just checked in r3202 which I believe fixes the root cause of #1796 in a reasonably correct way. I think it also fixes #2232 for the same reason. It all seems to come down to the import paths being used as dictionary keys and models being registered twice. See the change for the way I am working around this. Russ: can you see if I've overlooked any problem there, please. It took a little while to track everything down and my brain may have gotten twisted in the process. Also, I left it alone for now and I realise you were just cutting-and-pasting, but __import__ takes dictionaries as the second and third arguments (globals() and locals(), basically, although the third arg is essentially ignored); why are we passing in strings??? I can no longer cause #1796 or anything like it to fail -- and I had a couple of failing examples there. I believe relative imports (appname.models, etc) might now work reliably too (experiments suggest they do), which means you no longer are reliant on your project name and can create portable apps. Feedback welcome/appreciated. I may have screwed up in some subtle way. Regards, Malcolm --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: RFC: Django history tracking
Uros Trebec wrote:
> > Sounds nice, this is a feature I'm currently looking for... but I've
> > already started my own implementation.
>
> Nice! Do you have anyting in code yet? Any bottlenecks?
>
sorry not yet. But will come, I need it for my current development.
>
> > I would just share it with you.
> >
> > I've build a single table History with :
> > - "change"; a text field which will contain a python pickled
> > dictionary: { field: old_value} in case you update a record.
>
> How does this help/work? Why dictionary? Can you explain?
>
I should add first that my history table can contain history of any
other table. In fact I don' t have an history table per "master" table.
This is a kind of "generic" history, thus I don't know the type of data
I will save in it. I solve this by pickling the data and save them into
a textField, that's the goal of the "change" field.
For flexibility reasons, I let possibility to select the field people
want to have in their history table.
Does this is better explained ?
> > - type: type of modification (update, delete, insert).
>
> Is this really necesary? How do you make use of it?
>
I take inspiration from svn log files. Sure this is necessary!!.
History is a kind of record trace from his creation up to his delete
(if occurs). But I'm agreed that most of the case, "insert" and
"update" are really useful. Concerning the "delete", this would be
useful if you want to have "undo" functionalities.
> > - "obj": the table object. This can come from ContentType
>
> I don't understand...
>
As I've explained, my "history table" can record history data of any
table I'm interested. Thus "obj" and "obj_id" give me possibility to
build a link between the history and the "master table".
> > - "obj_id": the id of the impacted object.
> > - create_date: a timestamp automatically set.
>
>
> > I'm using it by sub-classing the save methods in each model I want to
> > see the history.
> > This is quite flexible, because you can decide which field you want to
> > track.
>
> I agree. But I fail to see the need for not versioning the whole record/row.
>
>
> > To facilitate, yet one step further, it would be nice to have a
> > PickledField within Model.models of django.
>
> Can you elaborate on that?
behind the scene, Django will unpickle and pickle when you access the
data in a PickleField. This will avoid to have a model like this:
class History(models.Model):
change = TextField()
def get_change(self):
return loads(change)
def set_change(self,data):
change = dumps(data)
Imagine you have 3 fields with Pickling functionalities in the same
table ...
>
>
> > Feedbacks are welcome.
>
> Same here! :) And thanks for your feedback!
>
Thanks for the questions. I hope I'm a bit clearer ;-).
I hope I'll have a bit time this week to tackle this problem, and come
with real code.
William
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
TEMPLATE_STRING_IF_INVALID bug
Hello all, I've found something that looks like a bug. When I add TEMPLATE_STRING_IF_INVALID = 'INVALID' to my config, first page of admin (i.e. http://127.0.0.1:8000/admin/) is rendered without 'Django administration' headline. -- Sincerely, Vladimir "Farcaller" Pouzanov http://www.hackndev.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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
Malcolm Tredinnick wrote: > I've just checked in r3202 which I believe fixes the root cause of #1796 > in a reasonably correct way. I think it also fixes #2232 for the same > reason. It does (just checked). Marking ticket fixed... Thank you very much, Malcolm and Russel and everyone else! --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
Hi Russel, > 2) I have seen the behaviour from r1796 before - for me, the problem > ultimately turned out to be caused by a PYTHONPATH that included the > application directory (so "from myapp.models import Foo" and "from > myproject.myapp.models import Foo" were both legal). At the time, I > chalked it up to the pythonpath, and moved on (sorry - can't give any > more specific details as to SVN revision, exact code structure, etc). I think this points right to the root cause of the issue. manage.py mangles the PYTHONPATH such that both "import myproject.models" as well as "import myapp.myproject.models" work. However, Python doesn't recognize that both statements refer to the same source file, so if you have both variants in your code, it will import the same module twice! Steps to reproduce: Create a project with a single app, and a module in the app which prints a message if it is imported: miraculix:~/test martina$ django-admin.py startproject proj miraculix:~/test martina$ cd proj miraculix:~/test/proj martina$ ./manage.py startapp app miraculix:~/test/proj martina$ echo 'print "in app.m"'>app/m.py Now, run it under manage.py: miraculix:~/test/proj martina$ ./manage.py shell Python 2.4.1 (#2, Mar 31 2005, 00:05:10) Type "copyright", "credits" or "license" for more information. IPython 0.7.0 -- An enhanced Interactive Python. ? -> Introduction to IPython's features. %magic -> Information about IPython's 'magic' % functions. help-> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [2]: import proj.app.m in app.m In [3]: import app.m in app.m In [4]: import app.m In [5]: app.m is proj.app.m Out[5]: False Line 2 and 3 show that both variants are accepted, and that python doesn't treat them to be identical (otherwise, line 3 wouldn't print "in app.m", as line 4 shows.) Line 5 furthermore shows that the modules aren't identical as well. Now let's run this without manage.py: miraculix:~/test/proj martina$ ipython Python 2.4.1 (#2, Mar 31 2005, 00:05:10) Type "copyright", "credits" or "license" for more information. IPython 0.7.0 -- An enhanced Interactive Python. ? -> Introduction to IPython's features. %magic -> Information about IPython's 'magic' % functions. help-> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: import proj.app.m --- exceptions.ImportError Traceback (most recent call last) /Users/martina/test/proj/ ImportError: No module named proj.app.m In [2]: import app.m in app.m In [3]: import app.m In [4]: In this case, only the variant "import app.m" is allowed, and no ambiguity arises. I think this ambiguity should be resolved. What's the reason that manage.py adds the current directory to the pythonpath? Could this be removed? One problem would be that this would break a lot of code that uses "import project.app..." ciao Martina --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
Malcolm Tredinnick wrote: > > I can no longer cause #1796 or anything like it to fail -- and I had a > couple of failing examples there. I believe relative imports > (appname.models, etc) might now work reliably too (experiments suggest > they do), which means you no longer are reliant on your project name and > can create portable apps. could you please try what i described here: http://tinyurl.com/kkpgw for me it still fails :-( gabor --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
On Mon, 2006-06-26 at 00:58 +1000, Malcolm Tredinnick wrote: > I've just checked in r3202 which I believe fixes the root cause of #1796 > in a reasonably correct way. I think it also fixes #2232 for the same > reason. It all seems to come down to the import paths being used as > dictionary keys and models being registered twice. See the change for > the way I am working around this. > > Russ: can you see if I've overlooked any problem there, please. It took > a little while to track everything down and my brain may have gotten > twisted in the process. Also, I left it alone for now and I realise you > were just cutting-and-pasting, but __import__ takes dictionaries as the > second and third arguments (globals() and locals(), basically, although > the third arg is essentially ignored); why are we passing in strings??? > > I can no longer cause #1796 or anything like it to fail -- and I had a > couple of failing examples there. I believe relative imports > (appname.models, etc) might now work reliably too (experiments suggest > they do), which means you no longer are reliant on your project name and > can create portable apps. By the way, I'm pretty sure there are (or should be) some "reverse relation" bugs still present, for the same reasons as these two bugs. They were there before and are no worse than previously. I just need to trace through the reverse lookup stuff a bit more carefully. I'll fix them in the morning, but my brain is fried right now and it's nap time. Best wishes, Malcolm --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
On Sun, 2006-06-25 at 18:36 +0200, gabor wrote: > Malcolm Tredinnick wrote: > > > > I can no longer cause #1796 or anything like it to fail -- and I had a > > couple of failing examples there. I believe relative imports > > (appname.models, etc) might now work reliably too (experiments suggest > > they do), which means you no longer are reliant on your project name and > > can create portable apps. > > could you please try what i described here: > http://tinyurl.com/kkpgw > > for me it still fails :-( I just sent of another post before this one arrived: I'm aware that reverse relations still have problems. It's the same root cause, but not the identical problem as #1796. I'll fix it when I can. Regards, Malcolm --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: ManyToManyField looks broken
On 6/25/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Russ: can you see if I've overlooked any problem there, please. It took
> a little while to track everything down and my brain may have gotten
> twisted in the process.
The anti-model-duplication logic makes sense to me from what I
understand of the problem, everything still works for me locally, and
it seems to have fixed Ivan's problem. I'm happy to call this a
victory.
> Also, I left it alone for now and I realise you
> were just cutting-and-pasting, but __import__ takes dictionaries as the
> second and third arguments (globals() and locals(), basically, although
> the third arg is essentially ignored); why are we passing in strings???
Honest Mum! - It was like that when I got here :-)
I can't think of any reason why strings are being used for globals and
locals - running a quick check, using None, {} and actual calls to
globals() and locals() in place of the empty strings all work equally
well (or, at least, don't cause the regression tests to fail).
Looking at the Python library docs, it almost seems that the
globals/locals parameters don't matter. Quoting
http://docs.python.org/lib/built-in-funcs.html#l2h-6:
"In fact, the standard implementation does not use its locals argument
at all, and uses its globals only to determine the package context of
the import statement."
Given that we're doing our own package context magic, it looks like we
could provide almost anything with these two parameters without
affecting behaviour of the model loader. Unless anyone can point to a
specific problem that is caused by the empty strings, I'm happy to
leave this in the "ain't broke, don't fix it" category.
Russ %-)
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: TEMPLATE_STRING_IF_INVALID bug
On 6/25/06, Vladimir Pouzanov <[EMAIL PROTECTED]> wrote: > > I've found something that looks like a bug. I just tried and got the same thing. I've opened ticket #2237 to follow the problem, and added you to the CC list for that ticket. Thanks for the report, 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
