xisting
data but others are just allowed to add new data).
Don't you think that the implementation of (current) Model.save()
should be broken into Model.add() and Model.save()? Adding a new entry
and updating an existing one are _different_ operations and the should
not be *automagically* fu
Hey Arvind --
This question is really more appropriate for django-users
(http://groups.google.com/group/django-users/); django-dev is for
discussion of developing Django, not for discussion of using Django.
You'll have a lot more luck if you redirect your question to
django-users.
Thanks!
Jacob
On 2/28/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I wanted to use UUID as primary key in my models. Since Model doesn't
> have any add() method, I have to do it like this:
For the future - this question should be asked on the users list. The
developers list is for discussion of
Thanks for the reply Jacob,
But I intentionally posted it here. Reason: I am *not* asking about
how to use Django, the document is (mostly) excellent! But I accept
any comments on my usage. :-)
I actually want to point the Django developers to the implementation
of Model.save() and am trying to
On 2/27/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
> while not self.id:
> # we are adding new row
> id = ''.join(str(uuid.uuid4()).split('-'))
> try:
...
First, I wouldn't be concerned about collisions i
> First, I wouldn't be concerned about collisions in uuid generation
> unless I was working on space probe software.
>
> Second, the code would loop nearly never, meaning O(1) on average.
> Worst case is worse, but again, unless you're saving lives, it's fine.
Exactly! But not just O(1). I should
> I should be able to do it with just one
> hit at the database. Second (and subsequent) hit(s) should occur only
> in the case of an insert exception (AssertionFailed). But the way
> Django doesn't differentiate b/w INSERTs and UPDATEs, I have to
> manually check for collisions and hit the databa
On 3/1/07, David Danier <[EMAIL PROTECTED]> wrote:
...
> Perhaps save() could be change to actually do this:
> (As I started writing my own DB-abstraction-layer once, I know this can
> become very handy)
> ---
> def save(self): #
> self._update()
> else:
> self._insert()
> ---
Yes, yes! That's exactly what I am trying to suggest for so long...
Model.save() which uses Model.add() and Model.add() can be used
separately (and independently
> If you abandon the record check when pk_set, then you lose the ability
> to manually specify an ID for use in insert.
Thats why the comment above says "simplified", perhaps it was
oversimplified...:
---
def save(self): # not so
> The current code is:
> if pk_set:
> check if a record with that pk exists.
> if it does, do an update.
> if it does not, do an insert.
> else:
> do an insert.
>
> If you abandon the record check when pk_set, then you lose the ability
> to manually specify an ID for use in insert.
That's
On 3/1/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
...
> That's ok. All we are trying to say is that INSERT code should be a
> separate function which can be used independent to UPDATE code.
...In which case, you'd get still get an error if there was a
collision on ID, and you'd still need to gen
> ...In which case, you'd get still get an error if there was a
> collision on ID, and you'd still need to generate a new ID and try
> again. I guess you're just trying to avoid the "check if a record
> with that pk exists" bit on inserts? And you (the app dev) would be
> responsible for handlin
> If the id already exists, you will overwrite the record; if it
> doesn't, it will be created. This is the same behaviour as your
> approach.
This is exactly what I DON'T want to do and Django ALWAYS does.
> For the future - this question should be asked on the users list. The
> developers list
14 matches
Mail list logo
