|
History
| Log In
|
|
|
|
Should automatically create a sequence for the ID field if one does not already exist
From Chris H: For apps with multiple clients / concurrent transactions binding needs optimistic locking support in order to be reliable.
Binding or storing objects by ID breaks connected graphs in an incompatible way to our reference system.
Ideally a module that attaches outside values back to persistent objects operates outside db4o and traverses values ( possibly using code already present in dRS ) and sets them on the persisted objects without changing their identity. Please see my replies in this thread...
http://developer.db4o.com/forums/thread/47309.aspx ...in our forums, especially this one: http://developer.db4o.com/forums/permalink/47309/47256/ShowThread.aspx#47256 Carl,
I understand your point regarding how ID's are created internally and used by db4o. Is it not possible, however, to give db4o the ability to generate an identifier for objects that is for use by the client application and which is independent of db4o's internal ID? I see that the UUID provides this, but not in a way that is convenient to use on the object, and such long identifiers are not human friendly. This is a major problem for my intended use of db4o. Many applications, web or otherwise, need to generate human readable ID's for objects that can then be used as shorthand for that object. Such client/server applications must generate these id's from a single store that is aware of the previously created ID's. Developers have depended on the auto-increment capabilities of RDBMS's to provide these in the past. These ID's start out as logical object ID's in the database, but they frequently become *business* ID's as the application is used (order number, part number, claim number, ticket number, etc.). This ID could then be used by the application (and it's users) to identify the object externally. It would be used just as any other field on the object would be used; but since it was uniquely generated by db4o, it would be guaranteed to be unique within the container and would be persistent. db4o would not need to concern itself with updates to the ID. A proper design could mitigate that possibility as well. By human readable, I mean a number (or potentially string) on the order of 5-8 digits. In most cases, a simple integer count starting at 1 for each object type would suffice. But you could trick it up with formatting capabilities as well. I'd be perfectly content with the former. Here's hoping you reconsider, Keith Imagine an RESTfull application that need IDs to reference objects (as links):
Next URL shows an Invoice: http://server/context/invoices/<id> the HTML representation of invoice, also shows an Provider (name) that links with: http://server/context/providers/<id> note: this HTML link send new request to web server (new connection/ObjectContainer starts) and must return the requested provider; and shows a list of invoices that links with their details (using invoice url). Of course, this links can referenced by other web applications. for example: when use accepted known IDs as IBAN, ISIN, CURRENCY, ... http://server/bank/accounts/<iban> http://server/bank/assets/<isin> http://server/bank/currency/<iso_a3_currency> It's possible a "human readable" UUID as Long? (without change internal object references)
note: that "human readable", in this context, is short and sequential number (auto-increment), for example: - sequential per DDBB: UUID stores a unique long - sequential per Class: UUID stores a ClassName (or hashCode) and long There is a Technical reason to do this feature? (please, avoid retro-compatibility reasons) I think that it's a very important feature to identify objects (and RESTful applications that use short and human readable URLs) Any response? @Jose Illescas
Have an indexed field initialized by the Class Constructor : final long datCreate = (System.currentTimeMillis() << 24) | (System.nanoTime() & 0xffffff) If you use <<20 ou can get back the Date to get human readable signification (but you have risque of collision (1 / 1 048 576) if your API have regularly new instances of the same class in the same millisecond (I doubt of this) (N.B. : with <<21 you have to test if negative). Like your field is inexed, it is relative to a Class. With dateCreate, you have no need of UUID tool, and your instance, even if replicated it is, keep one and only one ID, even if it is replicated or copied in other container. Claude P.S. : IMHO db4o team manage cleverly UUID, you have to cope with their choice to developp only what is needed by database management (not for users eases like in RDBMS closed sources), unless you provide a better one, intricated in all internal constraints. 1° ) Just a precision : if you use <<24 you can correct Date like
(datCreate >> 24 )| (1L << 40) to have correct time. 2°) I have not tested replication without UUID, so add UUIDs if you have to replicate. 3°) @Carl Rosenberger from 2° above : if I have all my classes with a field indexed and uniqueConstraintKey on it and others classes are static is it necessary to use UUID for replication? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
ID Systems
1. Annotation to mark a field that is to be treated as an ID
2. (Additional option as alternative to reusing GUIDs) The option to use one db4o-managed sequence per-class that can have a starting value of 1 so that ID's are more human-readable.
3. Would like to be able to define an ID field plus getter/setter in a base class, annotate that, and then have db4o still assign descendants have one sequence per class. Don't want to have to repeat the field/annotation in every class, and don't want to have to do it through Config for every affected class either.
Please take a look at the Java Persistence API's annotations, and their options:
@SequenceGenerator *
@GeneratedValue
* I think that a user-provided generator is overkill. It might be a convenient non-defaul option perhaps. I think one sequence per class, or reusing GUID's would be sufficient (buts please lets have a choice between both of these as out-of-the-box functionality!).