Re: django-values -> django-policy?
On May 29, 4:56 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > I propose the boring-but-functional "dbsettings" -- settings stored in > the db -- and unless someone can come up with a REALLY good reason not > to use that, I'm going to make a dictatorial call to paint the > bikeshed MY color. +1. Jason --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
transaction management
Hi, I've got a problem with manual commits for transaction. Say I have a view function: @transaction.commit_manually def index(request): ... ... object.save() callOtherFunction() transaction.commit() The problem is that I will get a transaction management exception before calling the function in the body of index(). But I want to commit things only after this function. Is there any other way to do this, apart from disabling the whole transaction stuff (variable DISABLE_TRANSACTION_MANAGEMENT in settings as far as I remember) for the whole application? Thanks, Hubert Plociniczak --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Generic newforms media
On 5/30/07, Luke Plant <[EMAIL PROTECTED]> wrote: > > I've had to add hacks in before to get around the inflexibility of inner > classes. In those cases, there was good reason for those inner > classes -- Django needs to be able to get at the data they contained > before any instances of the outer class existed. I can't see the > corresponding reasons here, and I'm not at all convinced that the > neatness of representation of a DSL outweighs the functionality > disadvantages. You have some reasonable points here. I've just uploaded a new version of the patch that hopefully addresses your concerns. This new version preserves the DSL for the simple case, but if you want to manually define a media property to perform inheritance based changes, or if you want to select media based on some programmatic construct (such as locale), you can; a manually defined media property takes precedent over a DSL defined one. See the regression test for examples of usage. Does this satisfy your concerns? 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-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?hl=en -~--~~~~--~~--~--~---
Proposal: post_create signal
Hi all, I was thinking about using signals in one of my applications and tried to figure out which Django signals are sufficient for my purposes and where I may need some extended functionality. Due to this process, I was looking for a way fetch a signal after the creation of an object. Currently Django has the pre_save and post_save signals that will be send before and after saving the object. But there seems to be no way to determine whether an object has been just created or updated. I had a look at the django users mailing list, and found the following posts, which already mentions this problem. http://groups.google.com/group/django-users/browse_thread/thread/2e707d248e0b1e9f/5115906d26db8423 http://groups.google.com/group/django-users/browse_thread/thread/f5cd51f8ab71fd98/8cd476afedf8bdbd What I'm going to propose is an extra post_create signal that addresses this issue. Regards, Ben Schwarze --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
> Jacob Kaplan-Moss wrote: >> I'm going to make a dictatorial call to paint the bikeshed MY color. Jason Davies wrote: > +1. What part of "dictatorial" is not clear? ;-) -- Nicola Larosa - http://www.tekNico.net/ Microsoft went berserk; tried unsuccessfully to get me fired as co-editor, and then launched a vicious, deeply personal extended attack in which they tried to destroy my career and took lethal action against a small struggling company because my wife worked there. It was a sideshow of a sideshow of the great campaign to bury Netscape and I'm sure the executives have forgotten; but I haven't. -- Tim Bray, January 2007 --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
ticket ping: #3050 enable values() even with extra(select=...)
Hi all, I am well aware of the core devs' time shortage and have read recent threads about stale tickets. Ticket 3050 contains a failry trivial enhancement of django query module - it allows you to use custom DB expressions ( extra( select=...) ) even when using ValuesQuerySet. I have updated the patch to cooperate with current version. Tests are included. Could any of the core devs spare five minutes of their time and look over it please? It shouldn't take any longer (the patch only have 77 lines). thank you very much HK -- Honza Král E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Generic newforms media
On Wednesday 30 May 2007 14:39:12 Russell Keith-Magee wrote: > I've just uploaded a new version of the patch that hopefully > addresses your concerns. This new version preserves the DSL for the > simple case, but if you want to manually define a media property to > perform inheritance based changes, or if you want to select media > based on some programmatic construct (such as locale), you can; a > manually defined media property takes precedent over a DSL defined > one. See the regression test for examples of usage. > > Does this satisfy your concerns? That sounds great, thanks. I'm not personally that worried about this feature (I'm not making great plans around Widgets at the moment for myself), but just concerned that we won't be making an API for v 1.0 that will be needlessly inflexible. Best regards, Luke -- "I have had a perfectly lovely evening. However, this wasn't it." (Groucho Marx) 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: post_create signal
Ben Schwarze wrote: > Due to this process, I was looking for a way fetch a signal after the > creation of an object. > Currently Django has the pre_save and post_save signals that will be > send before and after saving the object. But there seems to be no way > to determine whether an object has been just created or updated. > Why not connect to pre_save and check whether the primary key is None, similar to the accepted way to check for creation if you override Model.save()? Rob :) --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: post_create signal
On Thu, May 31, 2007 at 09:16:07AM +1200, Robert Coup wrote: > Ben Schwarze wrote: > > Due to this process, I was looking for a way fetch a signal after the > > creation of an object. > > Currently Django has the pre_save and post_save signals that will be > > send before and after saving the object. But there seems to be no way > > to determine whether an object has been just created or updated. > > > Why not connect to pre_save and check whether the primary key is None, > similar to the accepted way to check for creation if you override > Model.save()? The most obvious reason, of course, is that you don't know at that point whether the save is successful or not. -Forest signature.asc Description: Digital signature
dbsettings
There's a new episode in the contiuing saga of django-values! Per Jacob's recent dictatorial decision (and given a lack of opposition thus far), I've renamed it to dbsettings, though the URL remains unchanged.[1] Other notable changes in this latest update: * Removed assumptions of being placed in django.contrib * Changed Options to Group (as it's really just a group of settings) * Added an app-level editor * Added a FloatValue * Added the option to supply choices for settings * Added Django-ready documentation And probably some others that I'm not thinking of at the moment. I've been staring at it for way too long today. Please give any feedback you have. -Gul [1] http://code.google.com/p/django-values/ --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: post_create signal
On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote: > Why not connect to pre_save and check whether the primary key is None, > similar to the accepted way to check for creation if you override > Model.save()? Forest already mentioned not knowing if the object persistence will be successful. In many cases using transactions will rollback any changes that happen if a problem pops-up later (assuming those changes are in the database). Another problem is with OneToOne relations. The primary key will be populated prior to save. Internally, Django solves this by querying the database to see if the object already exists. It would be possible to replicate this in a pre_save listener, but the result would be hitting the DB with three queries instead of the current two (and it's possible to do it with one -- see prior discussions about explicit .insert() and .update() methods). I'm +1 for adding a post_create signal to core. I've already implemented both pre_create and post_create on my own without too much hassle though. Also wanted to point out the fact that there is an existing ticket in the 'design decision needed' stage of its life-cycle. Same concept, just different naming. [0] - Ben [0] http://code.djangoproject.com/ticket/2154 --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: post_create signal
Benjamin Slavin wrote: > Forest already mentioned not knowing if the object persistence will be > successful. Fair enough :) > In many cases using transactions will rollback any > changes that happen if a problem pops-up later (assuming those changes > are in the database). > So the post_create signal would be triggered *after* the transaction was committed? The patch in 2154 certainly doesn't handle that case. Cheers, Rob --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: post_create signal
On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote: > So the post_create signal would be triggered *after* the transaction was > committed? The patch in 2154 certainly doesn't handle that case. That's not what I was trying to communicate. It was mentioned that you won't know if "the save is successful or not" if processing is done in pre_save. If it's called as is done in the patch, the save has been successful (assuming no future rollback), meaning that any problem wasn't with persistence of the object. Anyone needing to perform actions only after a successful commit is on their own with the version of post_create being discussed. (I think that's reasonable) - Ben --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: ticket ping: #3050 enable values() even with extra(select=...)
On 5/30/07, Honza Král <[EMAIL PROTECTED]> wrote: > Ticket 3050 [snip] Ask (so politely) and ye shall receive: http://code.djangoproject.com/changeset/5385. 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: post_create signal
Benjamin Slavin wrote: > On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote: > >> So the post_create signal would be triggered *after* the transaction was >> committed? The patch in 2154 certainly doesn't handle that case. >> > > That's not what I was trying to communicate. It was mentioned that > you won't know if "the save is successful or not" if processing is > done in pre_save. > I agree that checking post_save/pre_save doesn't work too well around create. Do you think it's better to have a single post_create signal to go with post_save/pre_save or the two signals (save_update & save_insert) as per #2154? > If it's called as is done in the patch, the save has been successful > (assuming no future rollback), meaning that any problem wasn't with > persistence of the object. > > Anyone needing to perform actions only after a successful commit is on > their own with the version of post_create being discussed. (I think > that's reasonable) > Fair enough :) Rob. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Custom field _post_create_sql()
Though I am not conversant with the details of the GIS fundas, here is
my observationtheir application gave a very good pointer to people
who always wanted to do custom field development. I wouldn't be happy
to see SQL statements be used in the class (even though it gets the
work because I believe there is another place for it in the
management.py or the data_types).
Here is what I did (not complete as yet):
Created a Check class which inherits the Field Class and write all the
attributes or methods here.
Next, in the management.py I make small changes and write the
appropriate SQL statements.
In management.py
In _get_sql_model_create(),
...
for f in opts.fields:
if isinstance(f, (models.ForeignKey, models.OneToOneField)):
rel_field = f.rel.get_related_field()
while isinstance(rel_field, (models.ForeignKey,
models.OneToOneField)):
rel_field = rel_field.rel.get_related_field()
data_type = get_rel_data_type(rel_field)
elif isinstance(f,Check):
# Write my SQL statements here.
else:
rel_field = f
data_type = f.get_internal_type()
col_type = data_types[data_type]
if col_type is not None:
# Make the definition (e.g. 'foo VARCHAR(30)') for this
field.
field_output =
[style.SQL_FIELD(backend.quote_name(f.column)),
style.SQL_COLTYPE(col_type % rel_field.__dict__)]
field_output.append(style.SQL_KEYWORD('%sNULL' % (not
f.null and 'NOT ' or '')))
...
Personally, I believe not all cases for custom SQL development require
SQL to be appended (like mine), so is there a necessity for
_post_create_sql() for my project???
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Design Decision: Dynamic settings.SITE_ID (ref. #4438)
I recently created and started testing a simple middleware, that I thought may even be worthy of django.contrib.sites. In brief, here's the question being asked: Is modifying settings, and in particular settings.SITE_ID, allowable? Is it workable? (ie, what breaks if that assumption does not hold?) Here's the impetus: myblogname.example.com can look friendlier and be easier to remember than example.com/myblogname. Many modern sites place user-controlled content under relatively dynamic subdomains (ie, new users might sign up any moment). It is also certainly advocated by many Rails philosophers. For most sites of this type it doesn't make sense to be required to build a VirtualHost file and a Settings file for each and every User/Blog/Project/Family Dog/Whatever. In those cases it makes sense to use wildcard (*) subdomain VirtualHost and a single settings file with a bunch of shared applications. I think the django.contrib.sites.models.Site seems perfect for the task of determining which Sites might be available at a given moment, and is an already existing way to configure applications to handle such. To make this as easy and nearly transparent to existing Site-based code I proposed a simple process_request middleware to set settings.SITE_ID to the id of the Site whose domain matches request.META['HTTP_HOST'] and I attached the code to a simple one that I started testing to Ticket #4438. [1] Here's where the debate begins... I would like to see something as simple as adding a middleware to support dynamic Sites rather than a single static Site for a settings file. But, can you modify the settings from a middleware? Should you? I don't think this sort of thing belongs in the view because it keeps someone from using unmodified/unwrapped generic views (which can often be a sign of a loss of DRY, right?) and because it makes a huge distinction between a website with a static, unchanging SITE_ID and a settings file that might host multiple SITE_IDs. It also doesn't belong in a Manager class because a Manager shouldn't need to deal with HttpRequest and if it did, it can't be used for filtering in a urls.py file if it requires a request object... I don't see a better alternative. [1] http://code.djangoproject.com/ticket/4438 What do you y'all think? -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Introduction to CRM
thanks man, I was looking for more information about how CRM works. On May 21, 4:04 am, Ankur <[EMAIL PROTECTED]> wrote: > Hi All, > > I just found a link which seems to be quite informative about CRM. > > Just try the link below to have a look at it. > > http://www.quazen.com/Business/Management/Introduction-to-CRM.25530 > > This contains the basics of CRM. I really loved this article. > > Thanks, > Ankur --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Design Decision: Dynamic settings.SITE_ID (ref. #4438)
On Thu, 2007-05-31 at 01:00 -0400, Max Battcher wrote: > I recently created and started testing a simple middleware, that I > thought may even be worthy of django.contrib.sites. In brief, here's > the question being asked: > > Is modifying settings, and in particular settings.SITE_ID, allowable? > Is it workable? (ie, what breaks if that assumption does not hold?) Every single piece of code that caches anything based on having read something from settings would then have to query settings every time (and recompute whatever it cached). There is code that relies on the current behaviour and the assumption that settings will never change once you access them makes this a useful pattern. Having to change this to "some settings will change" means there is always some flipping back and forth checking which set of assumptions you are operating under when developing. Feels error prone. I'm pretty stupid, so I'm a big fan of things behaving as expected with consistency. I personally also quite like the idea that settings are set entirely by the user of an application -- in the normal use-case of a settings file and a webserver -- and are not going to be messed around by code. This idea isn't axiomatic because of settings.configure(), but if you're using that it's an unusual situation and typical user configuration has changed in purpose slightly (and deliberately). An alternative approach to a solution for a problem that requires this question (can I change a setting?) is to work out whether it makes sense to move the "feature" away from being a setting (since it's no longer a user-configured setting, but the user setting can still act as a hint). [.. prologue elided ...] > I would like to see something as > simple as adding a middleware to support dynamic Sites That's the problem that might be interesting to solve! All the stuff about settings changes flows from your particular solution. Don't misunderstand me here: I'm not trying to dismiss on your solution -- I just want to distinguish between real barriers on the way to the goal and barriers imposed by other decisions. Two alternatives spring to mind. Neither of these are fully thought-out yet, but let's see how they sound: (1) We introduce a formal thread-local settings feature as well. Things that might change on a thread-to-thread basis (which corresponds to per-request in web-based operation and is a no-op, essentially, in scripts, etc) are accessed through this and it falls back to normal settings for things that aren't present. So normal usage of sites would not require changes and your sort of situation could put the SITE_ID key into this storage. We would need to decide which current settings could be accessed through this module, since all accessors would have to be changed. I've been thinking about this idea on and off for a bit, because it would also clean up some other pieces of code that do thread-local stuff (i18n settings, internally, being one example). (2) We come up a with a more dynamic site object. This is a little harder than it first seemed it might be. The problem isn't contrib.sites itself -- there are two changes necessary in there with regards to getting the current site and if we can find a way to specify what "current" is, changing those methods is easy. The problem is all the other places that access the sites module by querying the Site model directly. I guess replacing "settings.SITE_ID" with a new contrib.sites.get_current_site_id() method is a simple change there. Many cases can actually be fixed by using CurrentSiteManage in a couple of models (maybe not as the default manager), but a few are harder, so making settings.SITE_ID dynamic, via a function, might be easier. Not quite sure how to tell the sites package what the current site ident is for the current thread (yet). Conclusion -- I'm mostly in favour of making this type of functionality possible (feeping creaturism is the main argument against, but I'm always negative on new features for that reason). I realise your original question was motivated by not wishing to make any changes to the code at all and instead *just completely violate one of our most sacred, honorable and historic assumptions* (alright, you may not have viewed that way). I'd like to solve the problem in a slightly more intrusive way, though, just because I like viewing the settings module as a static thing. Which conflicts massively with my "I don't like random backwards incompat changes" inner child, but that's something I have to work out. Don't take my approach as anything close to gospel, though. I'm just first in line with a response. There will be other opinions. 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]
Re: Optgroups from nested choices in newforms (discussion of patch on #4412)
(Cleaning up some flagged items I've been meaning to respond to...) On Tue, 2007-05-29 at 03:56 -0500, James Bennett wrote: > I noticed a patch sitting on #4412 tonight which seems interesting but > definitely needs a decision; the idea is that, rather than > implementing a separate widget or set of widgets to handle grouping of > options (via the HTML "optgroup" element), the Select and > SelectMultiple widgets should look at the structure of 'choices -- if > it has a nested structure of grouped choices, those should translate > into optgroups in the rendered widget. > > Personally, I kind of like the simplicity of the approach and the fact > that it handles this use case without needlessly multiplying widgets, > so I'd give it a tentative +1. Aah... the old nested tuples as way of creating an ordered dictionary approach. Good value in languages that are built around S-expressions, but not something you necessarily want to read when programming Python. Alternatives are possible as bad, though (unless we insist that SortedDict is used there?). My only minor concern is that we are letting ourselves in for a large number of queries asking why it doesn't work with models. I think it's a *good* thing model fields still expect a sequence of pairs -- putting presentation into the data representation is uncool -- but that won't stop people trying to extrapolate. That feature should be documented so that it can be properly ignored. I'm probably between +0 and +1 here, I guess. It shouldn't be too harmful, there isn't really any existing support for optgroups, so people wanting to use them would have to write their own Select derivative, and they are useful for some kinds of lists. 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?hl=en -~--~~~~--~~--~--~---
Re: Design Decision: Dynamic settings.SITE_ID (ref. #4438)
On 5/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Every single piece of code that caches anything based on having read > something from settings would then have to query settings every time > (and recompute whatever it cached). There is code that relies on the > current behaviour and the assumption that settings will never change > once you access them makes this a useful pattern. Having to change this > to "some settings will change" means there is always some flipping back > and forth checking which set of assumptions you are operating under when > developing. Feels error prone. I'm pretty stupid, so I'm a big fan of > things behaving as expected with consistency. I'm starting to see this. In my testing there is an inconsistency from time to time in the results and/or the caching. > An alternative approach to a solution for a problem that requires this > question (can I change a setting?) is to work out whether it makes sense > to move the "feature" away from being a setting (since it's no longer a > user-configured setting, but the user setting can still act as a hint). Agreed. Hence the reason I try to make sure to provide the full story as I see it so that a little Root Cause Analysis can be performed. > > I would like to see something as > > simple as adding a middleware to support dynamic Sites > > That's the problem that might be interesting to solve! All the stuff > about settings changes flows from your particular solution. Don't > misunderstand me here: I'm not trying to dismiss on your solution -- I > just want to distinguish between real barriers on the way to the goal > and barriers imposed by other decisions. I'm not married to my solution and opening this discussion was precisely what I saw as finding a much better solution. I realize that I'm not an everyday Django coder and I've very rarely used Django's source as anything other than a reference when I have a question as a consumer of the framework, so I certainly realize that my first instincts might not be the best. > Two alternatives spring to mind. Neither of these are fully thought-out > yet, but let's see how they sound: > > (1) We introduce a formal thread-local settings feature as well. > (2) We come up a with a more dynamic site object. (1) sounds more generally useful. If you've been thinking about it for some time and it looks like it might solve/alleviate some other things along the line it might be the better approach.(2) does seem like a lot of work for a single (contrib) application, but having fewer checks against SITE_ID could be a nice benefit (reducing some over-reliance on django.conf.settings). > I realise your original question was motivated by not wishing to make > any changes to the code at all and instead *just completely violate one > of our most sacred, honorable and historic assumptions* (alright, you > may not have viewed that way). I just thought I might have found a simple minimal solution in a few lines of code. I don't mind realizing that my solution created more side problems than it was worth. It was a learning experience... I had assumed that the functionality didn't exist because few had thought about it and fewer used the sites application rather than roll their own thing. Now I know that I was wrong and the problem is a bit bigger than I first thought it was. I personally think that Dynamic Sites support of one form or another should be provided sometime by 1.0, just because I don't think django.contrib.sites is complete without. It's the sort of functionality a new person might assume it contains... It took me a while to get used to the idea that sites didn't bother to check the address at all and simply took SITE_ID for face value. > I'd like to solve the problem in a slightly more intrusive way, though, > just because I like viewing the settings module as a static thing. Which > conflicts massively with my "I don't like random backwards incompat > changes" inner child, but that's something I have to work out. I have no problem for seeing it solved the intrusive way if that's what makes the most sense for the problem set. Hopefully something like this can even be done without breaking too many backward compatibility eggs... -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: post_create signal
I've reconsidered the post_create signal issue, and can imagine that the pre_save and post_save signals may be extended. What about a simple additional attribute that wil be send. This could be fetched in listener functions (e.g. is_update=True/False)? I'm not that sure whether it would be an backwards-incompatible change, but it wouldn't blow up Django's core signals. And there would be still a pre and post signal. Any ideas about that? On May 31, 4:46 am, Robert Coup <[EMAIL PROTECTED]> wrote: > Benjamin Slavin wrote: > > On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote: > > >> So the post_create signal would be triggered *after* the transaction was > >> committed? The patch in 2154 certainly doesn't handle that case. > > > That's not what I was trying to communicate. It was mentioned that > > you won't know if "the save is successful or not" if processing is > > done in pre_save. > > I agree that checking post_save/pre_save doesn't work too well around > create. Do you think it's better to have a single post_create signal to > go with post_save/pre_save or the two signals (save_update & > save_insert) as per #2154? > > > If it's called as is done in the patch, the save has been successful > > (assuming no future rollback), meaning that any problem wasn't with > > persistence of the object. > > > Anyone needing to perform actions only after a successful commit is on > > their own with the version of post_create being discussed. (I think > > that's reasonable) > > Fair enough :) > > Rob. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
