Re: Trying ZODB, background in Relational: mimic auto_increment?

[Jean-Paul Calderone]

On Thu, 14 Aug 2008 16:15:11 +0200, "Diez B. Roggisch" <de***@nospam.web.dewrote:

>Jean-Paul Calderone wrote:

>On Thu, 14 Aug 2008 05:22:35 -0700 (PDT), Phillip B Oldham
<ph************@gmail.comwrote:

>>[snip]

How would one assign a unique ID to the root at that point?

Here's one way

class Sequence(Persistence):
def __init__(self):
self.current = 0

def next(self):
self.current += 1
return self.current

ticketSequence = Sequence()

class Ticket(Persistence):
def __init__(self):
self.id = ticketSequence.next()

Be aware that this isn't working concurrently. Depending on your
application, this can be mitigated using a simple threading.Lock.

ZODB has transactions. That's probably the best way to make this
code safe for concurrent use. A threading.Lock would make threaded
use safe, but wouldn't give you multiprocess concurrency safety.

Jean-Paul

[Diez B. Roggisch]

Jean-Paul Calderone schrieb:

On Thu, 14 Aug 2008 16:15:11 +0200, "Diez B. Roggisch"
<de***@nospam.web.dewrote:

>Jean-Paul Calderone wrote:

>>On Thu, 14 Aug 2008 05:22:35 -0700 (PDT), Phillip B Oldham
<ph************@gmail.comwrote:
[snip]

How would one assign a unique ID to the root at that point?

Here's one way

class Sequence(Persistence):
def __init__(self):
self.current = 0

def next(self):
self.current += 1
return self.current

ticketSequence = Sequence()

class Ticket(Persistence):
def __init__(self):
self.id = ticketSequence.next()

Be aware that this isn't working concurrently. Depending on your
application, this can be mitigated using a simple threading.Lock.

ZODB has transactions. That's probably the best way to make this
code safe for concurrent use.

But that's a great deal more complicated! It requires merging, and while
this of course is possible, you should have mentioned it because
otherwise the OP might run into problems.

Diez

[Christian Heimes]

Diez B. Roggisch wrote:

But that's a great deal more complicated! It requires merging, and while
this of course is possible, you should have mentioned it because
otherwise the OP might run into problems.

A lock doesn't do the job at all. ZODB supports clustering through ZEO.
Multiple ZEO clients can be attached to a single or more ZODB servers.
Any kind of thread based locking is local to each ZEO client.

You have to sync a sequence generator across multiple ZEO clients, hook
into the two phase commit protocol or use the conflict resolution hooks.
The problem is more complex than you think.

Christian

[Maric Michaud]

Le Thursday 14 August 2008 20:14:19 Christian Heimes, vous avez écrit*:

Diez B. Roggisch wrote:

But that's a great deal more complicated! It requires merging, and while
this of course is possible, you should have mentioned it because
otherwise the OP might run into problems.

A lock doesn't do the job at all. ZODB supports clustering through ZEO.
Multiple ZEO clients can be attached to a single or more ZODB servers.
Any kind of thread based locking is local to each ZEO client.

You have to sync a sequence generator across multiple ZEO clients, hook
into the two phase commit protocol or use the conflict resolution hooks.

You don't have too if you manage the conflict error anywhere else in the
program just manage the exception ConflictError and let the user retry later,
that will not happen that much on most application.

But,

The problem is more complex than you think.

Not that complex, strength of ZODB is right here, this entirely covered by the
introduction to zodb (ZODB/ZEO programming guide), see userdb and chatter
examples.

Christian

--
http://mail.python.org/mailman/listinfo/python-list

--
_____________

Maric Michaud