Re: Proposal: Revised form rendering
Don't forget support for HTML5 INPUT placeholders! Ideally these would
pull from a new attribute on the ModelForm object.
Would {% form %} output the tag, as well as the CSRF token, too?
--
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: Allowing models to influence QuerySet.update
Is nobody interested? I'm using this in production for auditing purposes and works just fine. If only it were built in, then I wouldn't have to monkeypatch :) I've rebased it to trunk again and it still works. On wo, 2010-06-16 at 14:38 +0200, Dennis Kaarsemaker wrote: > I know that queryset.update does not call .save() for each instance and > I know why. I even agree with it :) > > However, I'd like to have a bit more control over what update() does, > e.g. for auditing purposes. I know that I can simply write a few lines > of code near every update() call to do what I want, but that violates > DRY. > > I have created ticket #13021[1] and created a github branch[2] that > provides the following: > > * Two new signals: pre_update and post_update > The argument for these signals is the queryset and a dict of all > changes that will be or have been applied to the objects in that set. > > * An update() method for Model. > This method is a classmethod because it does not deal with instances > but querysets. It calls pre_update on all of its fields. > > * A pre_update method for Field that does nothing > Simply exists so that it doesn't have to be checked for > > * A pre_update method for DateField for auto_now magic > This method adds an update for the relevant field to the dict of > updates. This means that auto_now really is auto_now, also when > using update() > > * A patched QuerySet.update() to use the above features. > - It sends the pre_update and post_update signals > - It calls the models update method to update the kwargs dict > > * Tests and documentation for these features > > I've sent this proposal a few months ago and have kept the patch up to > date since. It still applies (I've just rebased it to trunk) and the > tests still pass. > > Thanks in advance for considering and commenting, > > [1] http://code.djangoproject.com/ticket/13021 > [2] http://github.com/seveas/django/tree/seveas/ticket13021 -- Dennis K. They've gone to plaid! -- 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: Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
Hi Mark, > For 'polymorphic.polymorphic_model' it would be 'polymorphic'. Is that correct this didn't work at all (or didn't work properly) before your patch, and now works properly, so one can put "polymorphic.polymorphic_model" into their INSTALLED_APPS and everything would work? Should one import polymorphic_model from polymorphic.__init__ and put "polymorphic" into INSTALLED_APPS? Should one import polymorphic_model from polymorphic.models and put "polymorphic" into INSTALLED_APPS? In few words, how does the models discovery work for this case with your patch? -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.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-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: Allowing models to influence QuerySet.update
Hi Dennis -- I'm not totally thrilled with this proposal, though perhaps there's some points I just don't get. As it is, though, I'm -0 on the idea. update() is supposed to be an optimization that's "close to the metal" of the database; adding potentially-hidden slow code to the mix rubs me the wrong way. In general, signals are a very dangerous thing: they make side-effects non-obvious, and make it hard to discover what's going to be called when. They also add a not-insignificant overhead. I'm of the opinion that they should be avoided except where critically important, and I don't see this to be one of those cases. On Wed, Jun 16, 2010 at 7:38 AM, Dennis Kaarsemaker wrote: > However, I'd like to have a bit more control over what update() does, > e.g. for auditing purposes. I know that I can simply write a few lines > of code near every update() call to do what I want, but that violates > DRY. I think you may have missed a few possibilities in your search for a DRY solution to the problem. If I was trying to add some audibility around QuerySet.update() I would: 1. Define a QuerySet subclass that extended update() to provide whatever hooks I needed (this could be a signal, perhaps, or just the code). 2. Make a Manager subclass that returned by QuerySet object from get_query_set(). 3. Use said Manager (or a subclass) on each model that I want the behavior on. This gives me control over *where* my added behavior happens, and it's completely clear to anyone reading the code that I've got a custom Manager; they can follow the trail to the update behavior. > * An update() method for Model. > This method is a classmethod because it does not deal with instances > but querysets. It calls pre_update on all of its fields. > > * A pre_update method for Field that does nothing > Simply exists so that it doesn't have to be checked for > > * A pre_update method for DateField for auto_now magic > This method adds an update for the relevant field to the dict of > updates. This means that auto_now really is auto_now, also when > using update() This is the part that I *really* don't understand -- why do you need all the extra mechanism? You've now added (num_fields * num_objects_in_queryset) function calls to each update() call... So yeah, I'm pretty against this proposal, *especially* as implemented. Now, all that said, there's a kernel here I'm interested in exploring. If you follow the steps I outline above, you could pretty easily make a reusable app that provided QuerySet signals, but that app would only work with apps that explicitly depended upon it. That is, if I wanted to receive update() signals from auth.User, I'd be SOL. This dovetails with an idea I had recently: I think it's probably about time we added a mechanism for apps to contribute methods or behavior to QuerySets. I haven't thought it out fully, but I think that the best way for you to proceed might be to consider the greater question of how we might go about allowing project-wide QuerySet extensions. 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-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: Allowing models to influence QuerySet.update
On Wed, Jul 28, 2010 at 9:37 AM, Dennis Kaarsemaker wrote: > Is nobody interested? > > I'm using this in production for auditing purposes and works just fine. > If only it were built in, then I wouldn't have to monkeypatch :) > > I've rebased it to trunk again and it still works. > > On wo, 2010-06-16 at 14:38 +0200, Dennis Kaarsemaker wrote: > > I know that queryset.update does not call .save() for each instance and > > I know why. I even agree with it :) > > > > However, I'd like to have a bit more control over what update() does, > > e.g. for auditing purposes. I know that I can simply write a few lines > > of code near every update() call to do what I want, but that violates > > DRY. > > > >From what I've seen, you're probably going to encounter some resistance to any proposal that includes adding new signals to the core, especially if they are never going to be used by the vast majority of developers, and especially if there is any workaround possible. In this specific case, is this not a problem that can be solved by a custom manager on the specific models that need this functionality? That way you don't RY so much: class ControlledUpdateManager(django.db.models.Manager): def update(self, *args, **kwargs): # pre-update code super(ControlledUpdateManager,self).update(*args, **kwargs) # post-update code class MyModel(django.db.models.Model): ... objects = ControlledUpdateManager() You can apply that manager to any models that need the same pre- and post- update code, or subclass from it, or use it as a mixin as necessary. -- Regards, Ian Clelland -- 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: Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
On Tue, Jul 27, 2010 at 2:39 AM, Mark Sandstrom wrote: > I've added a ticket with a patch for automatically discovering models within > a package without using the app_label Meta attribute. I can't quite follow what the motivation is here -- could you perhaps explain *why* you created this patch? What feature was missing that led you here? 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-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: Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
On Wed, Jul 28, 2010 at 10:34 PM, Jacob Kaplan-Moss wrote: > On Tue, Jul 27, 2010 at 2:39 AM, Mark Sandstrom > wrote: >> I've added a ticket with a patch for automatically discovering models within >> a package without using the app_label Meta attribute. > > I can't quite follow what the motivation is here -- could you perhaps > explain *why* you created this patch? What feature was missing that > led you here? If this is what I think it is, then it would be very useful for me: my "models" is a package, and because of this, every model within submodules needs an app_label in the Meta. I think it might be useful for people refactoring their ever-growing models.py Regards Rajeev J Sebastian -- 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: Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
On Wed, Jul 28, 2010 at 12:09 PM, Rajeev J Sebastian wrote: > I think it might be useful for people refactoring their ever-growing models.py That's maybe part of what I don't understand: I can't ever say I've seen a models.py so big that I felt the need to split it up. Or rather, I have, but in each case it was better design to break up the entire app into a few smaller ones. I just don't see a problem that, in the very rare case you *do* have a models.py that needs to be broken up, you have to manually specify app_label. 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-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: Allowing models to influence QuerySet.update
On wo, 2010-07-28 at 12:02 -0500, Jacob Kaplan-Moss wrote: > Hi Dennis -- > > I'm not totally thrilled with this proposal, though perhaps there's > some points I just don't get. As it is, though, I'm -0 on the idea. > update() is supposed to be an optimization that's "close to the metal" > of the database; adding potentially-hidden slow code to the mix rubs > me the wrong way. > > In general, signals are a very dangerous thing: they make side-effects > non-obvious, and make it hard to discover what's going to be called > when. They also add a not-insignificant overhead. I'm of the opinion > that they should be avoided except where critically important, and I > don't see this to be one of those cases. > > On Wed, Jun 16, 2010 at 7:38 AM, Dennis Kaarsemaker > wrote: > > However, I'd like to have a bit more control over what update() does, > > e.g. for auditing purposes. I know that I can simply write a few lines > > of code near every update() call to do what I want, but that violates > > DRY. > > I think you may have missed a few possibilities in your search for a > DRY solution to the problem. If I was trying to add some audibility > around QuerySet.update() I would: > > 1. Define a QuerySet subclass that extended update() to provide > whatever hooks I needed (this could be a signal, perhaps, or just the > code). > > 2. Make a Manager subclass that returned by QuerySet object from > get_query_set(). > > 3. Use said Manager (or a subclass) on each model that I want the behavior on. This would add boilerplate to each class and makes it nontrivial to do update() tracking for third party applications. I don't see why pre/post update signals are worse than pre/post save and delete. Signals itself are pretty lightweight (two function calls per update()) and are separate from the rest of the proposal. > This gives me control over *where* my added behavior happens, and it's > completely clear to anyone reading the code that I've got a custom > Manager; they can follow the trail to the update behavior. > > > * An update() method for Model. > > This method is a classmethod because it does not deal with instances > > but querysets. It calls pre_update on all of its fields. > > > > * A pre_update method for Field that does nothing > > Simply exists so that it doesn't have to be checked for > > > > * A pre_update method for DateField for auto_now magic > > This method adds an update for the relevant field to the dict of > > updates. This means that auto_now really is auto_now, also when > > using update() > > This is the part that I *really* don't understand -- why do you need > all the extra mechanism? You've now added (num_fields * > num_objects_in_queryset) function calls to each update() call... For making auto_now and similar functions work with update(). Currently auto_now fails in the face of update(), which is not documented. I chose to make auto_now work but could live with the current status being better documented and not having the above functionality. I could simply implement it for my projects as a listener for the pre_update signal :) > So yeah, I'm pretty against this proposal, *especially* as implemented. Are you against just the signals too (so, only the first of the four patches)? Your negative reactions seem to concern mostly the additions to Model and Field. > Now, all that said, there's a kernel here I'm interested in exploring. > If you follow the steps I outline above, you could pretty easily make > a reusable app that provided QuerySet signals, but that app would only > work with apps that explicitly depended upon it. That is, if I wanted > to receive update() signals from auth.User, I'd be SOL. This is why I think a pre/post update signal is a good idea. It is the same sort of signal as the _save and _delete signals which django has had for a long time. > This dovetails with an idea I had recently: I think it's probably > about time we added a mechanism for apps to contribute methods or > behavior to QuerySets. I haven't thought it out fully, but I think > that the best way for you to proceed might be to consider the greater > question of how we might go about allowing project-wide QuerySet > extensions. Oh, that's a neat idea. Quick brainstorm: - Having a settings.DEFAULT_MANAGER / settings.DEFAULT_QUERYSET setting so people can subclass QuerySet and use it as default Pro: Should be fairly easy to implement on the django side Con: Existing managers might need to be changed to subclass settings.DEFAULT_MANAGER instead of the current parent - Have an api to add functionality to the manager/queryset Pro: No rewriting of existing code needed Con: Feels like monkeypatching I don't yet know what I would prefer and will look for other ways as I don't fully like either of the above. -- Dennis K. They've gone to plaid! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send em
Re: Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
On Wed, Jul 28, 2010 at 10:45 PM, Jacob Kaplan-Moss wrote: > On Wed, Jul 28, 2010 at 12:09 PM, Rajeev J Sebastian > wrote: >> I think it might be useful for people refactoring their ever-growing >> models.py > > That's maybe part of what I don't understand: I can't ever say I've > seen a models.py so big that I felt the need to split it up. Or > rather, I have, but in each case it was better design to break up the > entire app into a few smaller ones. > > I just don't see a problem that, in the very rare case you *do* have a > models.py that needs to be broken up, you have to manually specify > app_label. I guess thats a different way of working, where you have a lot of smaller apps. It's just boring to repeat the same thing all over the code :D Regards Rajeev J Sebastian -- 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: Allowing models to influence QuerySet.update
On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker wrote: > This would add boilerplate to each class and makes it nontrivial to do > update() tracking for third party applications. I don't see why pre/post > update signals are worse than pre/post save and delete. Because the save/delete signals get called once when a single object is saved/deleted. An update signal would have to be called once for each object in the queryset. That is, if `SomeModel.objects.all()` returns a thousand results, `SomeModel.objects.update(foo='bar')` would have to call the update signals one thousand times. This is why I refer to update() as an optimization. If you must have Python-side behavior during a bulk update, iterate over the queryset and call save. If you want performance, do it in the database. There isn't a middle ground. > Signals itself > are pretty lightweight (two function calls per update()) and are > separate from the rest of the proposal. Doesn't matter how lightweight they are: cheap != free. We've benchmarked this before, and you're right that it's small. But anything that could potentially be called O(N) times needs to be very carefully considered here. > For making auto_now and similar functions work with update(). Currently > auto_now fails in the face of update(), which is not documented. Well, that's a documentation bug, then. FTR, auto_now and friends have been close to being deprecated for quite a while -- they're impossible to do easily and cheaply, and (again) are better done in-database. I'll probably start taking the steps to marking them deprecated in 1.3. > Are you against just the signals too (so, only the first of the four > patches)? Your negative reactions seem to concern mostly the additions > to Model and Field. Yes. 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-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: Allowing models to influence QuerySet.update
On wo, 2010-07-28 at 13:43 -0500, Jacob Kaplan-Moss wrote: > On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker > wrote: > > This would add boilerplate to each class and makes it nontrivial to do > > update() tracking for third party applications. I don't see why pre/post > > update signals are worse than pre/post save and delete. > > Because the save/delete signals get called once when a single object > is saved/deleted. An update signal would have to be called once for > each object in the queryset. That is, if `SomeModel.objects.all()` > returns a thousand results, `SomeModel.objects.update(foo='bar')` > would have to call the update signals one thousand times. > > This is why I refer to update() as an optimization. If you must have > Python-side behavior during a bulk update, iterate over the queryset > and call save. If you want performance, do it in the database. There > isn't a middle ground. As implemented in my github branch it is called once (well, twice, pre and post) per update() statement, not once per object. > > Signals itself > > are pretty lightweight (two function calls per update()) and are > > separate from the rest of the proposal. > > Doesn't matter how lightweight they are: cheap != free. We've > benchmarked this before, and you're right that it's small. But > anything that could potentially be called O(N) times needs to be very > carefully considered here. If it were called N times, i'd agree. But it is not. > > For making auto_now and similar functions work with update(). Currently > > auto_now fails in the face of update(), which is not documented. > > Well, that's a documentation bug, then. > > FTR, auto_now and friends have been close to being deprecated for > quite a while -- they're impossible to do easily and cheaply, and > (again) are better done in-database. I'll probably start taking the > steps to marking them deprecated in 1.3. Ah... that's unexpected. I presume that the deprecation will be followed by documentation on how to set this up in databases that support them? -- Dennis K. They've gone to plaid! -- 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: Allowing models to influence QuerySet.update
On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker wrote: > As implemented in my github branch it is called once (well, twice, pre > and post) per update() statement, not once per object. Okay, I missed that -- sorry. Doesn't really change how I feel about the feature, though: I don't see the point in needlessly complicating what's supposed to be a very thin wrapper around an UPDATE call. I haven't really heard a good argument *for* the feature -- "I want it" isn't a great argument, and there's already been a couple of suggestions to otherwise achieve the feature. 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-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: Allowing models to influence QuerySet.update
On wo, 2010-07-28 at 14:20 -0500, Jacob Kaplan-Moss wrote: > On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker > wrote: > > As implemented in my github branch it is called once (well, twice, pre > > and post) per update() statement, not once per object. > > Okay, I missed that -- sorry. > > Doesn't really change how I feel about the feature, though: I don't > see the point in needlessly complicating what's supposed to be a very > thin wrapper around an UPDATE call. I haven't really heard a good > argument *for* the feature -- "I want it" isn't a great argument, and > there's already been a couple of suggestions to otherwise achieve the > feature. But not yet a suggestion that integrates with third party applications without modifying them, which is one of the reasons I implemented this. (The other reasons basically come down to "i want it" as complete auditing, including update() is a requirement I have for a few projects) On the other hand, I see no reasons not to include the feature as it doesn't get in the way, is useful and comes with documentation and tests. It doesn't make update() more complicated to use and four lines of easy to understand code (2 for defining the signals and 2 for sending) are not difficult to understand either for people maintaining the code. -- Dennis K. They've gone to plaid! -- 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: Allowing models to influence QuerySet.update
On Wed, Jul 28, 2010 at 12:02 PM, Jacob Kaplan-Moss wrote: > Hi Dennis -- > > I'm not totally thrilled with this proposal, though perhaps there's > some points I just don't get. As it is, though, I'm -0 on the idea. > update() is supposed to be an optimization that's "close to the metal" > of the database; adding potentially-hidden slow code to the mix rubs > me the wrong way. > > In general, signals are a very dangerous thing: they make side-effects > non-obvious, and make it hard to discover what's going to be called > when. They also add a not-insignificant overhead. I'm of the opinion > that they should be avoided except where critically important, and I > don't see this to be one of those cases. > > On Wed, Jun 16, 2010 at 7:38 AM, Dennis Kaarsemaker > wrote: >> However, I'd like to have a bit more control over what update() does, >> e.g. for auditing purposes. I know that I can simply write a few lines >> of code near every update() call to do what I want, but that violates >> DRY. > > I think you may have missed a few possibilities in your search for a > DRY solution to the problem. If I was trying to add some audibility > around QuerySet.update() I would: > > 1. Define a QuerySet subclass that extended update() to provide > whatever hooks I needed (this could be a signal, perhaps, or just the > code). > > 2. Make a Manager subclass that returned by QuerySet object from > get_query_set(). > > 3. Use said Manager (or a subclass) on each model that I want the behavior on. > > This gives me control over *where* my added behavior happens, and it's > completely clear to anyone reading the code that I've got a custom > Manager; they can follow the trail to the update behavior. A bit of a seque, but I think this is a useful way to DRY this common need: http://djangosnippets.org/snippets/2117/ -- 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: Allowing models to influence QuerySet.update
On Wed, Jul 28, 2010 at 2:46 PM, Jeremy Dunck wrote: ... > A bit of a seque, but I think this is a useful way to DRY this common need: > http://djangosnippets.org/snippets/2117/ segue, but non sequitur is what I meant in any case. :-) -- 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.
postgresql last_insert_id issue
Hi,
I'm running trunk and I found an issue where my model's tablename
contains uppercase characters.
svn praise says this broke in r13363
r13363 russellm # Use pg_get_serial_sequence to get the
underlying sequence name
r13363 russellm # from the table name and column name
(available since PostgreSQL 8)
r13363 russellm cursor.execute("SELECT
CURRVAL(pg_get_serial_sequence('%s','%s'))" % (table_name, pk_name))
The issue is that table_name is not double-quoted when necessary.
Probably the string argument should be self.quote_name(table_name)
rather than just table_name.
--
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: postgresql last_insert_id issue
The patch here [1] fixes this if anyone feels like reviewing. This bug is
preventing me from using trunk on several projects at present, so it would
be great to get the patch checked in. It also fixes a number of other
problems people have been reporting, I believe.
Simon
[1] http://code.djangoproject.com/ticket/13821
On 29 July 2010 03:19, ryan_peaceworks wrote:
> Hi,
>
> I'm running trunk and I found an issue where my model's tablename
> contains uppercase characters.
>
> svn praise says this broke in r13363
>
> r13363 russellm # Use pg_get_serial_sequence to get the
> underlying sequence name
> r13363 russellm # from the table name and column name
> (available since PostgreSQL 8)
> r13363 russellm cursor.execute("SELECT
> CURRVAL(pg_get_serial_sequence('%s','%s'))" % (table_name, pk_name))
>
> The issue is that table_name is not double-quoted when necessary.
>
> Probably the string argument should be self.quote_name(table_name)
> rather than just table_name.
>
> --
> 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.
>
>
--
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.
