Support for large object graphs and deeply nested structures

[fullben]

The documentation and examples I have found only work with very basic objects that simply rely on the JacisClonable<T> and standard Java cloning.
I was wondering whether JACIS can be applied to use cases where the underlying data contains deeply nested structures, collections and circular references. For example, consider the following model:

public class Store {
  private List<Customer> customers;
  private List<Stock> stocks;
  ...
}

public class Stock {
  private Store store;
  private Product product;
  private long quantity;
  ...
}

public class Customer {
  private Store store;
  private String name;
  private List<Order> orders;
  ...
}

public class Order {
  private Customer customer;
  private Store store;
  private List<Item> items;
  ...
}
...

I assume that using the JacisClonable<T> interface is not an option for this case. Would I have to use an implementation JacisObjectAdapter<T, S> to define custom copy behavior for my objects? And if yes, would using JACIS then still be a viable approach for such a use case?
Let's assume I have about a hundred Stores. Considering that a single Store may hold houndred thousands of Stocks, thousands or even tens of thousands of Customers, each with hundreds of Orders, wouldn't any type of cloning (manually or automatically) incur a significant performance penalty?
Or would it be better in such a use case to de-couple the model by introducing artificial identifiers, so that e.g. a Store only maintains a list of Customer identifiers instead of direct object references?

[JanWiemer]

Thx for the question! It indeed addresses one of the central questions working with the JACIS store: How to bring the requirement to have an interconnected object graph and the requirement to have simple atomic objects for the JACIS store together.

I think your last idea to de-couple the model is the way to go. For object models like these I would use an individual store for each object type. A key for the store I would use an artificial key (or a real key like a name if appropriate). If one object references another only the keys for the other object is stored. The obvious drawback is that navigating the object graph gets cumbersome. To mitigate this problem I would introduce getters for the referred objects getting the store for the corresponding object type as parameter (or giving the getter access to this store in a different way). The getter uses the stored key for the references object, fetches it from the passed store and returns the obtained object.

If e.g. an order refers a customer this could look like:

public class Order {
  private String customerId;
  public Customer getCustomer(JacisStore<String, Customer> store) {
    return store.get(customerId);
  }
}

Storing the objects this way is necessary to avoid cloning the whole object graph to maintain the transaction view for the objects. I thought about solutions how the JACIS framework may do this automatically, but until now I refuse all ideas because they would introduce a lot of reflection magic...

[fullben]

I see. I'll give this de-coupled approach a go and see if this works for my use case :)

I also just created a PR to upgrade the MicroStream version to the next major release.