Activation depth and update depth
Brought to you by:
olivier_smadja
Menu
▾
▴
Hi,
Is the any option to set activation depth and updatedepth?
Ales
Hi Ales,
Currently, NeoDatis does have such a feature. We are working on it.
Thanks
Olivier
Thanks, looking forward to any news.
Ales
Hi,<br>
any news about defining activation and update depth?<br>
It would be nice to be able to specify activation depth 0 - in such case no fields would be activated and I would activate the object on demand by its OID.<br><br>
Do you think that this could be done in the near future? It is almost one year from my first question.<br>
Thanks for any news.<br>
Ales
Hi Ales,
This is currently implemented on the V2. For instance, you can set the depth for object loading
Query q = new CriteriaQuery(Country.class);
q.getQueryParameters().setLoadDepth(1);
And you can then refresh the object to get it full reloaded with:
odb.refresh(o, depth)
This is still a beta but the feature is there…
See you,
Olivier
Great!<br>
And is it possible to specify depth 0? I mean a featura a Db4o has, that in such case only instance of the object is created and no fields are populated. The field are populated on demand by separate call when needed.<br>
Ales
I believe that depth 1 for NeoDatis is equal to depth 0 for DB4o. In NeoDatis, with depth 1, only native attributes like String, int, boolean,…. are loaded. Is it the same than Db4o with depth=0?
Thanks,
Olivier
No, it is not the same.<br>
Db4o depth=0 means, that only instance is created and all attributes like String, Integer, … are null. Then you can call activate(obj, 1) to populate the String, Integer … with their values for the particular object..<br><br>This is very useful for opening very large object lists because you only get list of light weight instances and activate them on demand (for example only those displayed in a grid). Without this the database would be unusable with large datasets.
I understood. Well, I believe we can implement the same behavior in NeoDatis.
When a User has a list of 10000 objects and you call activate with depth=1 on the user, the list is populated with empty instances or the list comes empty and is only populated when accessed?
Thanks,
Olivier
I am not sure if I undestand well. I will try.<br><br>
public class Person {<br>
private String name;
private ArrayList children;
<br>}<br><br>
After querying with depth=0 the name==null, children==null.<br>
After querying with depth=1 the name=="John", children==unpopulatedlistinstance. <br>
Unpopulated list instance in Db4o means that the list has size=0.
<br>After querying with depth=2 the name=="John", children==populatedlistinstance. <br>
Populated list instance means that the size of list is nonzero and and all objects referenced by arraylist items are instantiated with depth=1.
I can query with depth=0, then call activate(person, 1) to populate native fields (String, …) and to instantiate lists with 0 size. Then I can call<br>
if (children != null) {<br>
activate(children, 1); // this activates all Person objects referenced by children items to depth 1, better would be with depth 0 IMHO (not sure why they decided to activate children with depth=1, maybe there is some reason)<br>}<br>
What is the default behavior if a user does not set the activation depth?
From my point of view it is vital that the concept of activation should be seamless to end-users. For example, if the activation depth is 0 the ideal behavior is that fields are auto-populated when you try accessing them for the first time. That way activation depth can be more of an optimization switch, not something that has to be explicitly coded against (i.e. check if the field is null, if so explicitly activate it, etc).
Setting activation depth is not responsibility of the end user. It is responsibility of the application. This has to be transparent to the end user.<br>
The application developer should ensure populating the fields when needed. We do this in the the domain objects in getters or setters - activate the object for the first time. If there is some "autopopulate on demand" feature, we could omit our code, but that is not a big issue for us. The key is to have ability to activate with depth 0.
Who is the "end-user" for you? For me, the end-user is the user of the API, the person who builds the application on top of the API.
OK, let say that the end-user is the user of the API (previously I have meant the end user of the application). The "autopopulation" (Db4o say "transparent activation") should be configurable, if I need it, I will switch it on, otherwise not.
What's the disadvantage of having it on?
Hi Akahanek and Cowwoc,
Current default behavior in NeoDatis V2 is to load all the objects that are connected to the one you have requested. so there is no depth restriction.
For the use case that this situation leads to an unwanted behavior like loading all the database or loading big lists, the user can manually set the load depth.
This is based on the user feedback of the version 1.9 that does not support this feature (configuring load depth) and most of them are happy with loading all the relations.
One thing that can be done too is to ket the user configure a global variable to set the default load depth. Like OdbConfiguration.setDefaultLoadDepth(…);
What do you think?
Thanks,
Olivier
To Cowwoc: Just guessing, there could be a use case when this automagic feature can be more "clever" than we need :). Why not let the end user decide if he needs it.<br><br>
To Olivier: Yes, the global configuration would be fine. But it is also very nice to be able to specify the depth for the particular query, as you have written at the beginning of this thread.
Ok. The possibility to define the depth for each query already exists and will continue. But, for use cases that need to always specify a depth for the queries, the global configuration will let do that once for all queries…
Olivier
Olivier,
For my part, I think a global query setting is only useful if you auto-populate fields outside the query depth. If you have to populate dependencies manually then you might as well set the depth manually on each of your queries (different classes will need different depths).
I want as few configuration options as possible. I expect NeoDatis to do the right thing most of the time (i.e. sensible defaults) and only provide options for rare exceptions (and even then, only if there is enough community interest).
I cannot agree with the statement "as few configuration options as possible". What is the right behaviour in some use case could be not as good in some other cases and vice versa. If NeoDatis is supposed to be a general tool used in different use cases, it should have more than only a few config. options.<br><br>
Yes, I know, that this could be very difficult for newbies, but there could be a reasonably chosen default configuration so that a new user does not have to tweak it.
akahanek,
From personal experience, the more configuration options you add, the harder it is for end-users to use the software and for the developers to maintain it.
As mentioned before, I am in favor of adding configuration options *on demand*. If users bring up real-life use-cases (not theoretical "I think I'd need this one day") and there is sufficient demand for this feature (a large enough group of people ask for it) then it makes sense to add.
There is no point to working on theoretical demands only to discover later that no one needs them. Just my 2 cents ;)
cowwoc, you are right! I agree, that big amount of config options is harder to developer to maintain. But for the end user this is not a big issue when a default value for every option exists. The user has to follow the rule "Do not touch it if you do not understand it". I am not a car mechanic and do not know much about car engines, but I am able to drive a car :)<br><br>
I agree with adding some features on demand. Some features of NeoDatis could be obviously a "must have" feature and the developers do not have to wait for a demand for it. But again, I think generally we are on the same boat :)