> whats wrong with overridng save, then calling the super.save() ?
Technically, nothing wrong :-). It would be cleaner, in my opinion,
if the developer just defined a pre_save() and post_save() methods
without needing to wrap and return super.save() calls all the time.
Also, there is the repeti
On 4 May 2008, at 02:24, Leo Soto M. wrote:
>
>
> I'm specially interested in your work with Lucene, because it should
> be easily adaptable to work on Jython, and Django on Jython is my SoC
> project :).
>
> Will you post status reports to this list once you get started? I'd
> like to follow you
On 4 May 2008, at 07:31, mrts wrote:
> Good luck with the project!
>
> Has something been decided on using db backend full text search
> facilities as a convenient start?
Well, it already has decent support for Solr, and many other backends
have been started.
> The point is that indexers are
In fact this question would be better addressed to a more general list,
such as the comp.lang.python newsgroup (also available as
[EMAIL PROTECTED]). See
http://mail.python.org/mailman/listinfo/python-list
for further information.
regards
Steve
[EMAIL PROTECTED] wrote:
> django-develope
OK, so, we appear to have two camps:
1. People who think this should be handled by introducing one or more
new methods to allow easy differentiation of the cases.
2. People who think this should be handled by adding new keyword
arguments to save().
And, techncially, a third camp consistin
In the db-api docs under "one-to-one relationships", it still reads:
The semantics of one-to-one relationships will be changing soon, so we
don’t recommend you use them.
Is this still relevant after qs-rf? It seems like it is just more
"undocumented" than "changing semantics" now.
--~--~---
On Sun, May 4, 2008 at 7:02 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> The first is to look at the update() method that already exists on every
> QuerySet and every default manager: this method *already* does one of
> the things we want, namely force an UPDATE query to run. So, without
> a
Let's not quote me if you don't understand what I'm saying.
The patch we applied at Curse did the following (and solved some extra
queries):
- Added an _is_stored attribute on instances, default value was None
- _is_stored became True upon an instance retrieval via a QuerySet
- _is_stored became
On Mon, May 5, 2008 at 1:00 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> This may not directly solve the problems that are being referred to, but it
> was a bug fix none the less, and I believe it is relative to the issue at
> hand.
I never said it wasn't a *possible* solution, I just said it wa
Let me also bring up once again, that this is what all the other major DB
layers that I've looked at do. So it doesn't seem like it's a bad solution
at all.
On Sun, May 4, 2008 at 11:11 PM, James Bennett <[EMAIL PROTECTED]>
wrote:
>
> On Mon, May 5, 2008 at 1:00 AM, David Cramer <[EMAIL PROTECTED
10 matches
Mail list logo
