I am thinking of
OID insert( byte data ).
I think that the policy could be configurable. For an application which could support floating OIDs, the default would be to defer the assignment of the 64-bit identifier until the record was serialized and allocated on a page image. The big win here is in clustering of OIDs and/or records based on their “mature” state.
For an application which can not support floating OIDs, the OID would be eagerly assigned – exactly as it is today.
I think that we might benefit from an OID object for several reasons, not the least is that it will end our constant creation of Longs.
I would see at least the following methods on OID:
long getPageId(); // just the page identifier.
int getSlot(); // the slot on the page.
long longValue(); // the entire 64-bit long value.
Supporting floating OIDs would require the application to abstract the reference to the persistent object. What I had in mind for the GOM framework was supporting persistence by reachability – an object which is not reachable from a named (root) object in the store is not persistent and will never be assigned a fixed OID. This gives you the same functionality for transient and persistent data, which is nice.
[mailto:email@example.com] On Behalf Of Kevin Day
Sent: Tuesday, April 11, 2006 12:00 PM
To: JDBM Developer listserv
Subject: re: [Jdbm-developer] record managment
Given that the insert() operation returns a recid that is then used extensively by other objects in the store, how do you see this working? Are you talking about not having a long recid that is returned for object references, but instead having some sort of 'reference' object? I do this in my applications, but you have to handle serialization specially for the reference objects...
> I am wondering if we could define
the record management API in terms of an
------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Jdbm-developer mailing list Jdbmfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/jdbm-developer