0 votes
asked in Misc by (140 points)
Is it basically possible to use two or more object graphs in one and the same application? If yes, is it recommended to split a huge database into different object graphs, for instance to simplify writing my queries by using streams and to accelerate my streams by iterating through smaller object graphs?

2 Answers

0 votes
answered by (1k points)
One database has one root element, as far as I can see. But every database has several objects graphs (every object you save is an object graph). But thats not what you are asking as far as I understand. I guess you still think about how to design this database, which is totally different to the table approach. I am also new to MicroStream and can't really give you an advice. But so far I am thinking about a structure like following:


|- List<User> users; <-- List<Adress>, ...

|- List<Bill> bills;

|- List<...> others...

That way you can access all your object lists via your root? But again, I am also new and not sure about this design yet.
commented by (1k points)
Anyways with this aproach lazy loading would be important as you else would load the complete database in your memory.
0 votes
answered by (580 points)

There are different answers to different aspects of this question, mostly because of the paradigm shift from table-wise thinking to graph-wise thinking, as Fred already said.

Some simple statements:

One MicroStream database always has exactely one root object.

One application can have an arbitrary number of MicroStream databases (= StorageManager instances).
(But beware of mixing references between them, since references handling, lazy references, etc. will get mixed up and create inconsistencies)

One root object can point to an arbitrary number of object graphs. Each one is then simply a sub graph of the whole graph.

For example:
We have a customer project that has to handle 3 clients internally in the same application.
So they are technically 3 databases with the same structure but different data.
3 object graphs with one root object each.

How to handle that with just a single root object?
A superordinate "clients" collection points to the 3 client-roots.

This pattern holds for any number of graphs and any level of complexity.
You can always add another "layer" of nodes in your graph and thus combine multiple (sub-)graphs referenced by a single superordinate root, thus creaing a new super-graph that points to everything else. Without any overhead in performance or memory to speak of.
This is a completely different thinking from designing data structures in tables, but it is incredibly flexible and powerful AND even easier once one has switched the thinking over to it.

I did application development in tables with SQL myself for a few years and I experienced that paradigm shift confusion myself. During the transition, there were constantly moments where I thought "Can I just do that...? Yes!" and "Is it really that simple when purely working with a graph...? Yes, it is!".

This would be it, except there's one more point.

Actually, #1 is not entirely true.
True is: There is exactely one dedicated root object for the whole graph / the whole database.

However, constants in Java classes have to be resolved correctly to avoid inconsistencies during loading. Usually, such constants are just value type instances or otherwise stateless or immutable. Like in JDK BigDecimal.TEN or Collections.emptyList(). However, no one prevents anyone from writing a constant with mutable content, say a reference into the persistent object graph. On a technical level, this would be no different than the dedicated root object and all of a sudden, a single object graph / dataase would have any number of root objects.

We strongly recommend NOT to do that since it can quickly explode into design confusion and inconsistencies. The way described in #3 is much cleaner and less error-prone.

Notes: Every question must be a separate forum post. Headline: Formulate your question shortly and precisely. Thank you!
Powered by Question2Answer