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 bac
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
(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
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?
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
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 ho
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 bel
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 mentione
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
"Dj
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 succe
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_crea
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 ma
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 i
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 objec
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 b
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 chang
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
> 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
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.
Currentl
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 oute
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
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
22 matches
Mail list logo
