Extended mapping-definitions

The described feature is not available in any object-db I know, but possible with mapping to a relational DB, for example with Hibernate.

By default every entity of the real world (respectively its class) gets mapped to a java class. So cats get mapped to the java class 'Cat', dogs to 'Dog' and so on.

In the project for which I'm evaluating objectDB, there 1.) will be hundreds of classes and 2.) not all classes are known at project start (an editor).

To deal with especially the 2. limitation, the editor doesn't model his data with java-classes directly, but with a so called MetaClass. A MetaClass is a simple Java class, which mimics it behavior, for example it has an attribute for the name of the class.

Now this leads to the following problem:

By default a Java object gets persisted depending on its java-class. But in this case all the instances would be saved in the same 'table' (or what objectDB calls the space to save entities), called 'MetaClass'. And so apples and oranges gets mixed and no useful index can be build, etc.

In Hibernate you can specify a custom mapper, where you can change how an object gets converted to a persisted entity.

In simple words it would be the following:

If you have to persist an object obj which is an instance of 'MetaClass' don't persist it to the 'table' MetaClass,

but read the value val = obj.getName() and persist it to the 'table' called as the value.

The rest of the custom persister (e.g. for persisting lists etc.) could be the same as a default mapper / persister.

Is this possible to do with objectDB or anything else to get the problem done?

With best regards,

Thomas

You suggest storing instances of one class in different 'tables'.

Please clarify:

• Is it only for improving performance, or do you also expect a change in functionality?
• How exactly performance should be improved if the functionality remains the same?

You suggest storing instances of one class in different 'tables'.

-> Yes

Is it only for improving performance, or do you also expect a change in functionality?

-> Yes, it is only for improving performance (see below).

How exactly performance should be improved [...]

-> It depends on how objectDB stores java-objects. Does it store them depending on their java-class? So an instance of the java-class 'Dog' would be stored in a different table than an instance of 'Cat'?

I have only the analogy to a relational DB where:

1) by default, instances of different java-classes get stored in different db-tables

2) In my case: every class in the real world does not get modeled by an individual java class, but with the same java class 'MetaClass' and only the name-attribute of MetaClass distinguishes the real-world-class.

Example: cat in our wolrd -> instance of the Java Class MetaClass with MetaClass.className = "Cat"

dog in our world -> instance of the Java MetaClass with MetaClass.className= "Dog"

As consequence I would get a huge main-table with the default-mapping, containing dogs and cats mixed up.

Querying would not be as performant as with storing different real-world-entities in different tables.

For example: querying for cats would lead to the table 'metaclass', containg all real-world-classes.

So first the db has to go through all elements and fishing the elements with className = 'Cat'.

So it is a performance issue depending on how objectDB maps entities to the internal 'tables'.

Maybe it already maps same java-classes to different 'tables' depending on their attribute-values, or does other performance optimizations.

In Hibernate you can provide a custom-mapping to deal with this special problem.

I don't know if A) in objectDB it is even neccessary and B) if it is possible.

This is an interesting idea. Thanks for sharing it. But as you wrote, it is unclear if it necessary just for the sake of performance. More thinking is required.

You may be able to work with one large table efficiently using proper indexes. You can also use composite indexes that consist of the className field with other fields in order to retrieve required data efficiently.

Another idea, you can still use different entity classes, by generating them on the fly (there are several Java libraries that can do that).