Re: [MR] -- adding functions to a model from another model
On 4/21/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > > Hi Limodou. > Thanks for the reply. > > what I was trying to do was slightly different. > > def all_models_setup_post_init(): > for ct in Comments.get_content_types(): > ... add the query objects to the ct's model > > so i have two problems.. the first is: > - is there some dispatch thing I can connect to so that this function > gets called at the right time I think this will be not so easy. First I think you should have a target function, and new feature will apply on it. Then you could write some pre-process or post-process function, and invoke them just like decorator. For example: A.py class A(models.Model): def fA(self):pass B.py from xxx import A def pre_process(func, *args): do_something() return func(*args) A.fA = pre_process(A.fA) or you could use dispatch I think. Just like django orm has done. The model is in django/dispatch. > > the second is: > - how to add the functions, which I think you have answered. > > regards > > > On 4/21/06, limodou <[EMAIL PROTECTED]> wrote: > > > > On 4/21/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > > > > > > ok.. the subject sounds a bit confusing, but here's what i want to do. > > > > > > the comments table in contrib has a model with the following two fields > > > > > > content_type > > > and object_id > > > > > > I would like to create 'helper' functions on the refering model. > > > (ie.. have a comment_set query object on a blog-post model for example) > > > > > > > > > how does one go about doing this? > > > naturally I don't want to edit the blog-post model at all If i can help > > > it.. > > > I want the comment table to construct this post_init, or something. > > > > > > but my python and MR skills are lacking.. any hints from the gurus ? > > > > > > > from xxx import Comment > > > > def funca(self): > >pass > > > > setattr(Comment, 'funcname', funca) > > > > or just > > > > Comment.funcname = funca > > > > I think is ok. > > > > -- > > I like python! > > My Blog: http://www.donews.net/limodou > > My Django Site: http://www.djangocn.org > > NewEdit Maillist: http://groups.google.com/group/NewEdit > > > > > > > > > > -- > [EMAIL PROTECTED] -- blog: http://feh.holsman.net/ -- PH: ++61-3-9818-0132 > > If everything seems under control, you're not going fast enough. - > Mario Andretti > > > > -- I like python! My Blog: http://www.donews.net/limodou My Django Site: http://www.djangocn.org NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~-~--~~~---~--~~ 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: [MR] -- adding functions to a model from another model
On 4/21/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > so i have two problems.. the first is: > - is there some dispatch thing I can connect to so that this function > gets called at the right time To clarify a bit after some late-night IRC chatting about this: What Ian's trying to do, basically, is set up a method on a model which will fetch the comments associated with instances of that model. I suggested, and roughly sketched out, a custom manager to do this so that, say, a Story model could do 'Story.comments.filter(object_id=5)' and get a QuerySet of the comments for the Story with id 5. Would this be something worth fleshing out to possibly add to django.contrib.comments? I can see some uses for it, but I also think in most cases it'd be redundant with the template tags the comments app provides. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
A few i18n issues on M-R
Hi, I just posted some issues with i18n in M-R on django-i18n: http://groups.google.com/group/Django-I18N/browse_thread/thread/26cc1ad95bf845bd Two of the issues are very easy to solve, by adding 'verbose_name' to the ManyToMany fields of the User and Group model. For the other issues I do not have a fix (yet). Rudolph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
#1373 magic-removal: MySQL does not support DROP CONSTRAINT
There was a diff submitted by Geert Vanderkelen awhile ago. It doesn't apply cleanly to 'core/management.py' anymore. Is there a reason it wasn't commited? If I fix it to work with current release will someone commit it? I assume svn ci is restricted. --~--~-~--~~~---~--~~ 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: #1373 magic-removal: MySQL does not support DROP CONSTRAINT
On Apr 21, 2006, at 7:10 AM, njharman wrote: > There was a diff submitted by Geert Vanderkelen awhile ago. It > doesn't > apply cleanly to 'core/management.py' anymore. > > Is there a reason it wasn't commited? Most likely nobody got a chance to look at it until the patch no longer applied cleanly :) > If I fix it to work with current release will someone commit it? I > assume svn ci is restricted. Yes, please do. FYI, our patch policy and information about how commit access works lives at http://www.djangoproject.com/ documentation/contributing/. Jacob --~--~-~--~~~---~--~~ 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: magic-removal call for testing
>By way of process - Is the plan to make a formal release after the merge, or >will the "MR Trunk" be allowed to settle a little longer before we formally >tag a release? And, to follow a previous disussion, are we going to tag the >current state of trunk as a 0.92 release reflecting all the trunk fixes >since 0.91? Please keep in mind that translators need a chance to update their translations after M-R hits trunk. So I would say that a tagged release should be something like two weeks after M-R hits trunk, that way all translators should have a realistic chance to update their translations. bye, Georg --~--~-~--~~~---~--~~ 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: #1373 magic-removal: MySQL does not support DROP CONSTRAINT
Jacob Kaplan-Moss wrote: > On Apr 21, 2006, at 7:10 AM, njharman wrote: > >>There was a diff submitted by Geert Vanderkelen awhile ago. It >>doesn't >>apply cleanly to 'core/management.py' anymore. >>If I fix it to work with current release will someone commit it? I >>assume svn ci is restricted. > Yes, please do. new patch attached to ticket 1373 diffed against MR-r2717. Passes unittest. Works for mysql, assumed other backends work. --~--~-~--~~~---~--~~ 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: magic-removal call for testing
On Thursday 20 April 2006 22:26, Adrian Holovaty wrote: > At this point, Django's magic-removal branch is stable enough that > we're ready to begin the merging process. I've been running the > branch on chicagocrime.org for a couple of weeks with no problems. As > of right now, Jacob and I are freezing feature additions to the > branch and concentrating on fixing any remaining bugs and -- more > importantly -- updating ALL of the documentation. Great news Adrian. I was just about to add my CsrfMiddleware into contrib (see other thread) - but now you've called feature freeze. Shall I still go ahead and add it? It can't affect anything else since it isn't actually used anywhere. Luke -- "If you're not part of the solution, you're part of the precipitate." (Steven Wright) Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ticket #347 mysql engine used for tables
Ticket marked wontfix. Seems rather harsh to force MySQL users into editing output of manage.py and commands like 'install' just won't work. Politely asking if this decision might be reconsidered if a clean solution could be found. If not, a warning / note in the docs about the limitations of MySQL and workarounds would likely save some people from grief. btw the transaction unittests fail with mysql backend because default MyISAM silently accepts but does not implement transactions. -- norm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
models.py vs models/__init__.py
It's a bit hard trying to piece together the history of this from listarchives and tickets. It seems that putting models in a package instead of 'models.py' should work and is believed to work. I can verify that for MR-r2717 'models/__init__.py' does not work. In that 'manage.py sql' produces no sql for models. as outlined in this post to users http://groups.google.com/group/django-users/browse_thread/thread/454a9818f2786421/4e2cd192eb2588be#4e2cd192eb2588be There was some mention of __all__ so I tried adding that to my 'models/__init__.py' and listing my model classes but that didn't help. --~--~-~--~~~---~--~~ 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: magic-removal call for testing
This is great news. I've been using M-R for a couple months on a restricted-access production site and am very happy with it. --~--~-~--~~~---~--~~ 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: ticket #347 mysql engine used for tables
njharman wrote: > Ticket marked wontfix. Seems rather harsh to force MySQL users into > editing output of manage.py and commands like 'install' just won't work. Alternatively, set default table type in your database to InnoDB, and you're fine. Michael --~--~-~--~~~---~--~~ 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: magic-removal call for testing
On 4/21/06, Luke Plant <[EMAIL PROTECTED]> wrote: > Great news Adrian. I was just about to add my CsrfMiddleware into > contrib (see other thread) - but now you've called feature freeze. > Shall I still go ahead and add it? It can't affect anything else since > it isn't actually used anywhere. In the interest of keeping to our word about feature freezing, let's wait on this until after the merge. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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: ticket #347 mysql engine used for tables
Michael Radziej wrote: > njharman wrote: >>Ticket marked wontfix. Seems rather harsh to force MySQL users into >>editing output of manage.py and commands like 'install' just won't work. > Alternatively, set default table type in your database to InnoDB, and > you're fine. Didn't know such a thing was possible, how excellent. Thanks. command line --default-table-type my.cnf default-table-type SQL SET table_type=INNODB; --~--~-~--~~~---~--~~ 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: ticket #347 mysql engine used for tables
Hi, njharman wrote: > Michael Radziej wrote: >> njharman wrote: >>> Ticket marked wontfix. Seems rather harsh to force MySQL users into >>> editing output of manage.py and commands like 'install' just won't work. >> Alternatively, set default table type in your database to InnoDB, and >> you're fine. > > Didn't know such a thing was possible, how excellent. Thanks. > > command line --default-table-type > my.cnf default-table-type > SQL SET table_type=INNODB; Although correct, please note that TYPE is deprecated as of 4.0 and might disappear in MySQL 5.2 (it got dropped in 5.1.7 but got revered ;)) Try to use newer versions of these options when possible: --default-storage-engine=InnoDB SET [GLOBAL|SESSION] @@storage_engine=InnoDB and CREATE TABLE t1 ( id INT ) ENGINE=InnoDB Again, depends on which version you are using. Small overview here: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-8.html We might need to put that overview somewhere in manual though.. Gonna check that out. Cheers, Geert -- Geert Vanderkelen http://www.some-abstract-type-shit.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 -~--~~~~--~~--~--~---
broken comments application
Is there any chance http://code.djangoproject.com/ticket/1637 can be applied soon? The ticket seemed to have fallen off the radar, and I can't completely move to magic-removal (soon to be trunk) until comments work. Dave --~--~-~--~~~---~--~~ 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: broken comments application
On 4/21/06, Dave St.Germain <[EMAIL PROTECTED]> wrote: > Is there any chance > http://code.djangoproject.com/ticket/1637 can be applied > soon? The ticket seemed to have fallen off the radar, and I can't > completely move to magic-removal (soon to be trunk) until comments work. Which patch there is the "one true patch"(tm) ;) comments.3.diff? Joseph --~--~-~--~~~---~--~~ 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: broken comments application
On 4/21/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > Which patch there is the "one true patch"(tm) ;) comments.3.diff? Looks like it; it seems to match pretty closely with the patches I'd submitted on #1659, which cover parts of the comments app as well (and on that ticket, the most recent patches are, expectably, the correct ones). -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: broken comments application
On 4/21/06, James Bennett <[EMAIL PROTECTED]> wrote: > > On 4/21/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Which patch there is the "one true patch"(tm) ;) comments.3.diff? > > Looks like it; it seems to match pretty closely with the patches I'd > submitted on #1659, which cover parts of the comments app as well (and > on that ticket, the most recent patches are, expectably, the correct > ones). This should be fixed as of changeset 2272. Joseph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bug in django/contrib/admin/templatetags/admin_list.py
I posted this to django-users a few days ago but no one commented and I didn't see any mention of it here so I thought I'd repost to the dev group. I'm using M-R and just updated to 2721 and still didn't see a fix. If you use a FloatField in the admin list_display, you get an error rendering the template from line 160 in admin_list.py (TypeError, float argument required) 158.elif isinstance(f, models.FloatField): 159.if field_val is not None: 160.result_repr = ('%%.%sf' % f.decimal_places) % field_val 161.else: 162.result_repr = EMPTY_CHANGELIST_VALUE This is because FloatFields are stored as strings so you can't use one directly in a %f format. I think the line should be: 160.result_repr = ('%%.%df' % f.decimal_places) % float(field_val) But I'm not sure if that should be float() or Decimal(). Thanks, -Dave --~--~-~--~~~---~--~~ 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: ticket #347 mysql engine used for tables
Maybe I don't understand the implications but I have been using ENGINE=MyISAM on my tables so I can use MySQLs full-text indexing (not supported by InnoDB). Does this thread imply that I can no longer use MyISAM tables with MySQL? Or just that if I do, I must tweak the output of manage.py (which I already need to do to add the engine and fulltext clases). Thanks, -Dave --~--~-~--~~~---~--~~ 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: ticket #347 mysql engine used for tables
DavidA wrote: > Maybe I don't understand the implications but I have been using > ENGINE=MyISAM on my tables so I can use MySQLs full-text indexing (not > supported by InnoDB). > > Does this thread imply that I can no longer use MyISAM tables with > MySQL? Or just that if I do, I must tweak the output of manage.py > (which I already need to do to add the engine and fulltext clases). No, much the opposite. MySQL uses MyISAM by default. You have to do something extra to get it to use another engine. MyISAM doesn't do transactions. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---