I noticed this in my output when I did some inserts/sets to a reference
table:
12:01:06,102 INFO QueryLogger:315 - UPDATE PS_Collection SET identifier = ?
WHERE identifier = ? AND moniker = ? AND pRetainCount = ? AND typeDefinition
= ?
12:01:06,105 INFO QueryLogger:337 - [bind: < 00 00 00 00 00 00 00 22 40 08
03 2A >, < 00 00 00 00 00 00 00 22 40 08 03 2A >, 'LC', 1, '{class =
PSLocalSet;}']
12:01:06,112 INFO QueryLogger:368 - === updated 1 row.
It did an update to 'identifier' (the primary key) setting it to it's
original value. No harm done, but it seems to me it shouldn't have done an
update if nothing changed.
The join ordering I have is:
PSCollection <-> PSCollectionElement <->> PSItem <<-> FENotification
Here is the chunk of inserts/sets done in that part of the code (assume
collection and notification already exist):
// We need the config element to link to the collection element --
0x00000000000000224000024c is indeed a magic number
PSConfigElement configurationElement =
(PSConfigElement)
DataObjectUtils.objectForPK(notification.getDataContext(),
PSConfigElement.class,
HexCoder.decode("00000000000000224000024c"));
// Create the new collection element
collectionElement =
(PSLocalCollectionElement)
collection.getDataContext().createAndRegisterNewObject(PSLocalCollectionElem
ent.class);
// Link the collection element to the collection and configuration element
collectionElement.setCollection(collection);
collectionElement.setConfigurationElement(configurationElement);
// Create the new item
PSEnumeratedItem item = (PSEnumeratedItem)
collection.getDataContext().createAndRegisterNewObject(PSEnumeratedItem.clas
s);
item.setNotification(notification);
item.setCollectionElement(collectionElement);
item.getDataContext().commitChanges();
Here is the full SQL Cayenne used:
12:01:05,875 INFO SybstratePkGenerator:118 - Allocated 1 primary key(s)
12:01:05,990 INFO SybstratePkGenerator:119 - Key block range =
0x00000000000000225b1c615e:0x00000000000000225b1c615f
12:01:05,993 INFO SybstratePkGenerator:139 - Primary Key Vended =
00000000000000225b1c615e
12:01:06,015 INFO SybstratePkGenerator:118 - Allocated 2 primary key(s)
12:01:06,018 INFO SybstratePkGenerator:119 - Key block range =
0x00000000000000225b1c615f:0x00000000000000225b1c6161
12:01:06,020 INFO SybstratePkGenerator:139 - Primary Key Vended =
00000000000000225b1c615f
12:01:06,036 INFO QueryLogger:391 - --- transaction started.
12:01:06,041 INFO QueryLogger:435 - --- will run 3 queries.
12:01:06,050 INFO QueryLogger:315 - INSERT INTO PS_CollectionElement
(identifier, moniker, pcid, storePID) VALUES (?, ?, ?, ?)
12:01:06,079 INFO QueryLogger:337 - [bind: < 00 00 00 00 00 00 00 22 5B 1C
61 5E >, 'LE', < 00 00 00 00 00 00 00 22 40 08 03 2A >, < 00 00 00 00 00 00
00 22 40 00 02 4C >]
12:01:06,086 INFO QueryLogger:368 - === updated 1 row.
12:01:06,090 INFO QueryLogger:315 - INSERT INTO PS_Item (elementPID,
identifier, moniker, objectPID) VALUES (?, ?, ?, ?)
12:01:06,094 INFO QueryLogger:337 - [bind: < 00 00 00 00 00 00 00 22 5B 1C
61 5E >, < 00 00 00 00 00 00 00 22 5B 1C 61 5F >, 'ES', < 00 00 00 00 00 00
00 22 59 2E AA 2B >]
12:01:06,099 INFO QueryLogger:368 - === updated 1 row.
12:01:06,102 INFO QueryLogger:315 - UPDATE PS_Collection SET identifier = ?
WHERE identifier = ? AND moniker = ? AND pRetainCount = ? AND typeDefinition
= ?
12:01:06,105 INFO QueryLogger:337 - [bind: < 00 00 00 00 00 00 00 22 40 08
03 2A >, < 00 00 00 00 00 00 00 22 40 08 03 2A >, 'LC', 1, '{class =
PSLocalSet;}']
12:01:06,112 INFO QueryLogger:368 - === updated 1 row.
12:01:06,153 INFO QueryLogger:400 - +++ transaction committed.
My guess is that when ³collectionElement.setCollection(collection)² was
called, it somehow thought the primary key of the ³collection² object had
changed (it hadn¹t). I would also guess this has something to do with
binary primary keys. Strangely, though, it didn¹t try to do an update on
the PSConfigElement object when
³collectionElement.setConfigurationElement(configurationElement)² was called
(essentially the same kind of logic). I suppose you could apply that logic
to the sets on the item object, too ...
Like I said, no harm done, but it seems like a minor bug and if there is an
easy fix, maybe it should be made. I suppose I should step through the
code, too, eh? :-)
Anyway, I thought I¹d troll for comments to see if it was worth the effort,
etc.
Thanks!
/dev/mrg
This archive was generated by hypermail 2.0.0 : Tue Mar 01 2005 - 12:38:50 EST