I have a hierarchy of persistent 'Event' type classes, the base class of which stores a timestamp of millisecond precision and the app can produce an audit trail that orders objects according to this timestamp.
Initially I had big issues because MySQL uses its DateTime type to store Date objects and DateTime only stores time to within the nearest 'second' instead of Java's Date 'millisecond' precision. Quite often multiple objects were created in the same second which meant time based audit trails could result in events appearing out of proper sequence.
I resolved this by storing my own millisecond timestamp in a primitive 'long'.
However, the servers are so fast and I worry that occasionally some objects are going to be created in the same millisecond - much less likely than being created in the same second but still a possible issue (especially when I start running DataNucleus on our new Quantum technology servers - just jokes! - I think I need more than 16 bits to run a DataNucleus app :) ).
I thought a solution to this would be to configure the JDO query to order the objects by timestamp and then OID to ensure an 'order of creation' sorting sequence but as far as I can tell OID isn't an attribute that is available for use like other attributes in JDO queries or have I missed something and it can be referenced in a query?
I know I could do this in a native SQL query but I want to avoid using native SQL queries if possible - we've managed to do this so far - not a single native SQL anywhere in a MASSIVE code base and would like to keep it that way.
I guess as JDO and JDO queries specifically are meant to be implementation and datastore agnostic it might not be possible to reference a datastore specific id within a JDO query as that might break the 'agnosticism' policy.
As I've already said, using JDOHelper.getObjectId in a query gives you the datastore id (of sorts), and to look at what the SQL gives for use of that. Without factual details its impossible to comment further
