Creation of a complex object from several databases?

Question

Hello!
We need to have an ability to change certain property of the record, stored in the database, without reading the full record from the database, changing the property and updating the database with this new record. As far as I know there's no way for partial access to the record data (LOB access section from FAQ), so I am thinking in a bit different way - what if we keep the information of certain record in the different databases, and when we need to update some property of the record knowing the key - we will just update the appropriate database? This looks something similar to secondary databases when the secondary key is an alias for primary record - but in this case primary key would be referenced from several databases and it would be possible to specify which data from which database to obtain using the key?
I think it could be created based on several custom object bindings now, or something like this.

Answer 1

Eugene,
If you update properties in different combinations and there is no logical way to group them to reduce the size of the operations, then it's not worth splitting up the record. That's up to you to determine.
JE SecondaryDatabase and SecondaryCursor methods have overloaded signatures for returning the secondary key, primary key, and primary data, all in one method call. So I think you're confused about the method signatures -- the data parameter is always used to return the primary data.
Note that internally whenever you read via a secondary, JE does two reads: one to read the secondary index and get the primary key, and another to read the primary index.
There is no trick to get around doing multiple reads when you have relationships between different databases. Each primary and secondary database is an index or map (conceptually the same as a java.util.Map) that can be accessed by key or by iterating. Whatever you do must be built on top of map operations.
The best way to think about data modeling is to think about maps and their keys, and the best way to think about how to do a query is to break it down into map operations. I say this because most Java programmers are familiar with maps and map operations, because java.util.Map is commonly used.
The DPL (persist package) makes data modeling simpler to code and understand, because annotations can be used describe relationships between indexes. When using the DPL it is very clear that for every secondary index there is a secondary key, and that entity relationships are formed via secondary keys. However, the DPL model is still based on maps and map operations.
--mark