Hi all. I'm playing with standalone ZODB at the moment trying to get a better understanding of its use in applications. I come from a PHP/MySQL background, and I'm taking my first steps with Python at the same time. One of the things I'm not understanding about ZODB is assigning incremental IDs to objects. For instance, if I were to be writing a support-ticket system I'd want to give each ticket a unique number, but one that's "human-useable" (otherwise you could just use a UUID - try giving one of those over the phone!). Also, how would one add a new item to the db in this way? For instance: class Ticket(Persistence): def __init__(self): self.id = '' # How do I add a new incremental ID here? # and later on in the app tkt = Ticket() dbroot[?????] = tkt How would one assign a unique ID to the root at that point? -- Phillip B Oldham phillip.oldham@gmail.com +44 (0) 7525 01 09 01
----- Original Message ----- From: "Phillip B Oldham" <phillip.oldham@gmail.com> To: <zope@zope.org> Sent: Thursday, August 14, 2008 4:40 AM Subject: [Zope] Trying ZODB with a background in RDBMS
Hi all. I'm playing with standalone ZODB at the moment trying to get a better understanding of its use in applications. I come from a PHP/MySQL background, and I'm taking my first steps with Python at the same time.
One of the things I'm not understanding about ZODB is assigning incremental IDs to objects. For instance, if I were to be writing a support-ticket system I'd want to give each ticket a unique number, but one that's "human-useable" (otherwise you could just use a UUID - try giving one of those over the phone!).
One possible solution: - when you create a new ID store the ID somewhere you can easily retrieve it (eg. as a property field on a temporary folder - stored in memory, so constant writes of the ID do not bloat your ZODB; or stored as a record in an external DB) - create a routine that returns the stored ID; if the ID is not found then this routine would access the appropriate folder and return the highest ID found there - if you have a low-volume application you could skip the ID storage step and just look for the highest stored ID each time hth Jonathan
For a ticketing system, you could just use the unix timestamp as the ticket id. * 269-345-460 is my birthday... ( July 15, 1978) **121-873-549-7 is now.* (well, when this email was written). Anyway, these should be pretty easy to give over the phone. They are unique enough that you can take 59 calls a minute, 3599 calls an hour. It can also save you from storing another value "ticket open date/time". On Thu, Aug 14, 2008 at 1:40 AM, Phillip B Oldham <phillip.oldham@gmail.com>wrote:
Hi all. I'm playing with standalone ZODB at the moment trying to get a better understanding of its use in applications. I come from a PHP/MySQL background, and I'm taking my first steps with Python at the same time.
One of the things I'm not understanding about ZODB is assigning incremental IDs to objects. For instance, if I were to be writing a support-ticket system I'd want to give each ticket a unique number, but one that's "human-useable" (otherwise you could just use a UUID - try giving one of those over the phone!).
Also, how would one add a new item to the db in this way?
For instance:
class Ticket(Persistence): def __init__(self): self.id = '' # How do I add a new incremental ID here?
# and later on in the app
tkt = Ticket() dbroot[?????] = tkt
How would one assign a unique ID to the root at that point? -- Phillip B Oldham phillip.oldham@gmail.com +44 (0) 7525 01 09 01 _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Thanks, Derek Wilson
This may help in addition to Jonathan's suggestion. In PostgreSQL when you create a serial field for that purpose it actually creates an integer field with a modifier similar to this: not null default nextval(('"dl_articlereq_id_seq"'::text)::regclass) where dl_article is the table in which id is the integer field created. Also created is a sequence with this format: sequence_name | last_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called --------------------------------+------------+------------------------+------------------+---------------+-------------------+-----------+---------------+----------- dl_articlereq_id_seq | 288 | 1 | 2147483647 | 1 | 1 | 0 | f | t so you can get the last record value from last_value field. I'm feel sure mySQL is similar. Hope you can use this. Thomas On Thursday 14 August 2008 04:40, Phillip B Oldham wrote:
Hi all. I'm playing with standalone ZODB at the moment trying to get a better understanding of its use in applications. I come from a PHP/MySQL background, and I'm taking my first steps with Python at the same time.
One of the things I'm not understanding about ZODB is assigning incremental IDs to objects. For instance, if I were to be writing a support-ticket system I'd want to give each ticket a unique number, but one that's "human-useable" (otherwise you could just use a UUID - try giving one of those over the phone!).
Also, how would one add a new item to the db in this way?
For instance:
class Ticket(Persistence): def __init__(self): self.id = '' # How do I add a new incremental ID here?
# and later on in the app
tkt = Ticket() dbroot[?????] = tkt
How would one assign a unique ID to the root at that point?
-- ==================================================================== Thomas McMillan Grant Bennett Appalachian State University Operations & Systems Analyst P O Box 32026 University Library Boone, North Carolina 28608 (828) 262 6587 "... using OpenOffice.org, and save them back to disk automatically, in MS Word format. They surf the Web, check e-mail, do instant messaging, view YouTube videos, visit their Facebook pages, learn touch-typing skills and lots more. Our public library has been offering these Linux public stations for the past three years." - Phil Shapiro Linux Journal January 2008 Library Systems Help Desk: https://www.library.appstate.edu/help/ ====================================================================
Phillip B Oldham wrote:
Hi all. I'm playing with standalone ZODB at the moment trying to get a better understanding of its use in applications. I come from a PHP/MySQL background, and I'm taking my first steps with Python at the same time.
Heh, and just when people are moving more and more to ORMs like SQLAlchemy ;-)
One of the things I'm not understanding about ZODB is assigning incremental IDs to objects.
How important is it that they're strictly incremental? If it is, you may want to look at the BTrees.Length module. You can treat a Length a bit like a relational database sequence, provided you keep incrementing each time you use the Length's value as an id.
For instance, if I were to be writing a support-ticket system I'd want to give each ticket a unique number, but one that's "human-useable" (otherwise you could just use a UUID - try giving one of those over the phone!).
Well, the UUID you'd be thinking of would best be just the ZODB OID ;-)
class Ticket(Persistence): def __init__(self): self.id = '' # How do I add a new incremental ID here?
# and later on in the app
tkt = Ticket() dbroot[?????] = tkt
Well, if it was just plain ZODB, I'd do it as follows: from persistent import Persistent from IOBTrees import IOTree from BTrees.Length import Length class Ticket(Persistent): pass class TicketContainer(IOBTree): def __init__(self,id): IOBTree.__init__(self) self.next_id = Length() def addIssue(self): id = self.next_id() self.next_id.change(1) t = self[id] = Ticket() return t dbroot['tickets']=TicketContainer() It's very rare that a ticket needs to know its own id. If it does, it should ask its container. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2008-8-16 23:09 +0100:
... How important is it that they're strictly incremental? If it is, you may want to look at the BTrees.Length module.
"BTrees.Length" is unfit for the generation of unique ids, as it may hand out the same id to concurrent transactions. Other solution may do this as well but for them a "ConflictError" may be risen at transaction commit in this case. The "BTrees.Length"'s conflict resolution prevents such a "ConflictError". "Btrees.Length" might be used *PROVIDED* that the conflict is recognized at another place (e.g. by a folder that stores objects with the generated ids). But that are special cases. -- Dieter
participants (6)
-
Chris Withers -
Dieter Maurer -
Jonathan -
Phillip B Oldham -
SpiderX -
Thomas Bennett