RE: RE: [PEAR] 2 newbie Qs: DB_DataObjects

Thanks, Justin; The keys were created primary-first, so that doesn't seem a likely cause. In terms of the table perms, though, you raise an interesting question. The mysql account I'm using for the application doesn't have create_table privs, but I already created all the PEAR sequences using the root account, and the sequences themselves work fine in the 'production' account. However, if DB_DO uses its own sequences (i.e., something other than a 'users' sequence for the 'users' table), then there could be a perms problem underneath, and it could explain the disparities I see between the DB_DO-generated ID#s and the PEAR-generated sequences. For now, I'll get by with manually adding the PEAR sequence IDs. But if you (or anyone else who reads this) have any other bright ideas, I'm happy to hear them. Thanks again! --Chris -----Original Message----- From: Justin Patrin [mailto:papercrane@gmail.com] Sent: Wednesday, June 15, 2005 2:45 PM To: C.J. Mackie Cc: pear-general@lists.php.net Subject: Re: RE: [PEAR] 2 newbie Qs: DB_DataObjects On 6/15/05, C.J. Mackie <cjmackie@princeton.edu> wrote: > Thanks Dan, Justin; Cast does work perfectly: now I just have to > persuade my group to use it. (And Justin, tx for the tip re: > 'update()'. I picked that up from a tutorial, and thought it was > required.) > > I'm having trouble, though, reproducing the behavior you both say > should happen on inserts. My table has a primary key ('ID') with no > auto-increment, and a second, unique index on Email. Here's what I'm > finding: > > DB_DataObject::debugLevel(5); > $person = DB_DataObject::Factory('users'); > > $person->FName = "Dummy"; > $person->LName = "User"; > $person->Salutation = "Mr."; > $person->Email = "Dumuser@somewhere.edu"; $person->Phone = > "999.999.9999"; $person->PostalAddress = "Address"; $person->Password > > = md5('dummypass'); $person->Type = 0; $person->Active = TRUE; > > $person->fromValue('CreateDate',DB_DataObject_Cast::sql("NOW()")); > $ID = $person->insert(); > > produces: > > Users: Query Error: [db_error: message="DB Error: already exists" > code=-5 mode=return level=notice prefix="" info="INSERT INTO users > (Password , Type , Active , LName , FName , Salutation , Email , Phone > , PostalAddress , CreateDate ) VALUES > ('4518bda19425be276817a3b3eeee82b8' , 0 , 1 , 'User' , 'Dummy' , > 'Mr.' > , 'Dumuser3@somewhere.edu' , '999.999.9999' , 'Address' , > '2005-06-15 13:05:17' ) [nativecode=1062 ** Duplicate entry '0' for > key 1]"] > > I can't see any sign that the query even attempts to set ID. The > email address is definitely unique. The query succeeds when I empty > the table, but fails if there is even one record in the table already. > Emptying the table resets the DB_DO internal sequence to '0', which > isn't the documented behavior for PEAR sequences, I believe? Also, > the returned value $ID from > insert() is always '1', no matter what the actual value of ID in the table. Is there a tableName_seq table created? If not then the sequence isn't getting created. Sorry I can't really help you further as I haven't used DB sequences myself (I always use auto increment). However I know you can "fix" this by overriding sequenceKey() on the DO that's having troubles and having it return the "correct" values. Nope, I don't know what these are offhand. What order were your keys created in? Perhaps the email key was created before the ID key? Maybe try switching that? > > What am I missing? And is there a really good tutorial I can pick up > somewhere, to get myself up to speed more fully? > -- Justin Patrin