To One Relation improvements

[k0shk0sh]

Seeing the code generated for @Relation annotation, I think its not the right way to do it, the getter for lets say ClassA should check if the value is null first, and if it is, then should lookup for the One to One relation and query upon, however currently, the library forces us to always use the relationship generated method to return the data, how about if the data is not yet being saved? and we would like to display the result from the api immediately, because currently i can't seem to display the data returned due to the relationship generated code and the enforcing of loading the data for the variable from the objectBox which causes our variable to always be null.

[greenrobot]

Let's have the Customer/Order example: an order belongs to one customer. Thus the Order class has set/getCustomer() methods. Currently, you would have to put/attach an Order instance to ObjectBox before calling setCustomer(). In that case, the customer would be persisted.

However you would like to have non-persisted instances? Can you explain your use case a bit?

[k0shk0sh]

My example would be an API call. When the api call is finished, i would like to populate my adapter based on the list that I received, however, since the getters returns the one to one or one to many relation, theses values will always be null. Usually what i do
ApiCall->response (list of data, save it and then add the returned data from the api it to adapter

[greenrobot]

@k0shk0sh Usually you would want to get the data from an API, store it in the DB, and then show it in the UI.

[k0shk0sh]

Sorry about my earlier reply, i was using my phone and couldn't make myself clear.
The way i'm thinking of the scenario is as below:

1- Call API (Retrofit) with Pagination -> return List of items
2- If i detect its the first page, then only save the returned list.
3- upon saving that list, I'm not querying the DB instead, I have the list in my hand, why would I make another expensive call to load the list from db which it is in my hand and can just append it to my current list/adapter?
4- User now scrolls and reaches to the bottom, which indicates to call page two.
5- Now, there will be no saving process to happen.
6- User refreshes the list, returns to point 1.

I hope this clears things up.

[greenrobot]

From an architectural point of view, I advocate some data management abstraction layer. For the UI it should not matter where the data comes from. The abstraction layer can check for data in the DB or go to the server if necessary. And especially compared to a server call, persisting data in ObjectBox does not hurt, it's very cheap.

Another question I have: why would you want to store only part of the data? Wouldn't it be better to store all of it? Or why store any data at all?

Nevertheless, I acknowledge the potential for improvement here. I will keep that in mind when doing #18, hopefully there's a way to also allow transient relations.

[greenrobot]

#18 and V0.9.13 should resolve the situation. The other requirements seem rather special, not sure how we could implement them in a way that would be useful for others. Thanks!