Option of throwing LazyInitialisationException instead of returning nulls for non-loaded fields?

[artemik]

Some people might prefer a kind of LazyInitialisationException be thrown, instead of getting "null" for non-loaded lazy fields when lazy loading is disabled (especially project wide). That seems useful, because it allows more straightforward catching of cases where developers access non-loaded field by mistake. Yet, LazyInitialisationException has its own cons.

Could Ebean optionally have a project wide setting to enable throwing a kind of LazyInitialisationException instead of getting "null" for non-loaded lazy fields?

From here (https://ebean.io/architecture/compare-hibernate) it seems that the main idea behind absence of LazyInitialisationException in Ebean is because Ebean doesn't see harm in loading fields in another transaction under the default read committed isolation level. That makes sense. However lazy loading is often seen as an anti pattern and is avoided completely, so "null"s would just be returned instead, which has its own cons, as described above. Could Ebean maintainers share reasoning on why it was chosen to return null instead of an exception, when lazy loading is disabled?

[rbygrave]

when lazy loading is disabled?

Firstly, I believe this use case of "query where lazy loading is disabled" ... is actually better served by "query returning fully immutable read only entities"

That is, instead I want to execute a query that returns entities that:

• Do not lazy load
• Throw an exception when we try to access fields that are not populated
• Throw an exception when we try to mutate them [like call setters]
• Are effectively fully immutable

So this is actually the feature that I'm working on but haven't released yet etc. With this feature in mind we come back to the original question ...

why it was chosen to return null instead of an exception, when lazy loading is disabled?

Today to me this feels like it was a mistake, and I've had a couple of conversations with people that suggests it was a mistake.

The plan is to support queries that return fully immutable objects / object graphs. When we do that, and people can use that feature then I think it might be clearer that the "mutable beans but with lazy loading disabled" option is something people will not actually use in practice, that they will prefer the fully immutable query instead.

[rbygrave]

allowing writes but throwing on reads won't contradict anything. Afaik that's also how Hibernate works.

Can you show me an example of what you mean there? As in, Hibernate doesn't support partially loaded entity beans unless you are referring to relationships? Can you create a gist example so that I can understand? What you are suggesting would break Envers [just like it would break Ebean ChangeLog and other consumers of "old values"].

pre-checking field loading state

BeanState is what we use to find the loaded state of properties etc - https://ebean.io/apidoc/13/io.ebean.api/io/ebean/Database.html#beanState(java.lang.Object)

Writing a field shouldn't throw an exception, because it means users want to unconditionally set it, regardless of what value was inside previously. Yes, it might cause troubles

Well, on one hand we do approximately allow this for "stateless update" (no old values) but on the other hand this does break ChangeLog and perhaps persist handlers [things that "old values" are exposed to]. I think you'll need to provide a better description of the use case and why its mutating properties that are not loaded? [are they scalar types, lobs, relationships, why are they not loaded etc]

[artemik]

Oh I meant setting relationships only. Yes, Hibernate doesn't support partially loaded (simple columns) entities afaik (thanks for another reminder why Ebean is great :) ).

Doesn't Ebean currently allow setting fields without fetching them? I've never deliberately tested it, but somehow I assumed Ebean allows it? The docs show "stateless update", which is done via update() on a @Lob field there, but I assume the same is possible for save() and on any field as well, i.e. if a field is set, but previously it wasn't loaded, then this treated as a field update? If so, then yes, the things relying on previous values currently don't work in such case, but all I'm proposing is keeping that behavior if Ebean ever allows throwing Lazy exception on field reads?

Use case 1 (relationship field).
Backend receives an update of a Person with a new Employer ID (relationship field). We load that Person, but because we know the Employer field is going to be updated, we don't load the current Employer, instead we only load the new one and do person.setEmployer(newEmployer) and save? I know this specific case might be done better with just an update query, but that was just an isolated example, whereas in reality it might still be needed to actually load the Person anyway (for example, at least to trigger version increment).

Use case 2 (simple field).
lastUpdatedDate field. Why bother with loading the previous value if we know we're always going to set it to now() on every save unconditionally? This is a theoretical case, loading a simple date field isn't a big deal usually of course, but just as an example.

Use case 3 (simple field).
veryBigText field. Similarly, would be nice to just update it without loading the previous value? Imagine it's not necessarily a @Lob maybe, but still rather a heavy String field which would be nice to avoid loading?

The relationships cases are the ones I mostly care about, because avoiding JOINS sometimes might be a considerable benefit, unlike simple columns.

Is there a difference to Ebean (and to Hibernate?) in whether we're talking about setting simple or relationship fields without prefetching them?

[rbygrave]

Ebean currently allow setting fields without fetching them?

For Ebean this will invoke lazy loading. That is, calling a setter on a field that isn't loaded will invoke lazy loading. It does this in order to obtain the "old value" and that then supports ChangeLog and Persistence Listeners/Adapters that desire the use of the "old value".

So, not doing this would break Ebean ChangeLog (just as it would break Hibernate Envers) in that the "Old value" is now not known.

Note that an update like this does NOT break SQL2011 History support because that is all database side [where as ChangeLog, Persistence Listeners/Adapters, Hibernate Envers are all application side and the application side doesn't have the "Old value"].

Use case 1 - The relationships cases are the ones I mostly care about, because avoiding JOINS

So generally there are no joins required to fetch and update a ManyToOne with ebean [unless they are mapped via an additional join tables which imo is very rare]. A join is required on one side of the OneToOne, the side that doesn't have the foreign key columns needs to join over to the other side to obtain the foreign key value.

I don't think this is a valid concern really based on how ebean works in terms of the default fetch of a ManyToOne only includes the foreign key column and doesn't need a join.

Use case 2 - lastUpdatedDate field

Ebean @WhenModified gets special treatment meaning that Ebean will automatically set this for all updates regardless of whether that property was loaded on not [so that includes "Stateless update"].

I hope people use @WhenModified rather than setting this application side, and when they use it this case is handled automatically by ebean.

Use case 3 - large / lob field

This is a valid use case and it might occur reasonably frequently. Right now we would probably look to use a stateless update (or we could use BeanState setPropertyLoaded() to fake/override the loaded state of the large/lob field). This allows us to update a property without first loading it.

The concern here is that when we do this, we just need to remember that doing so means ChangeLog etc won't have the "Old value" available to it. This makes me wonder if there was a mechanism where people could explicitly opt into this, understanding the consequences - hmmm.

Is there a difference to Ebean (and to Hibernate?) in whether we're talking about setting simple or relationship fields without prefetching them?

It does sound like there is a difference there yes - I'll have to check that out case in Hibernate sometime, interesting.

[artpaym]

For Ebean this will invoke lazy loading.

What would happen if lazy loading is disabled project wide (DatabaseConfig is created with ebean.disableLazyLoading = true)?

no joins required to fetch and update a ManyToOne with ebean

Do you mean that the following:

// 1. load Person (default fetch strategy - only local/simple columns), load new Employer
// 2.
person.setEmployer(newEmployer);
// 3.
person.save();

will work without prefetching old Employer, because Person actually had foreign key (to Employer) prefetched?

If yes, it's great, this is the case I was mostly interested in. To note, for users this case might still look as if an update of a non-prefetched relationship is possible, because person.getEmployer() == null, yet the set... works just fine without fetching the actual employer.

So in the context of potential future Ebean's Lazy exceptions, if reading non-prefecthed relationships would throw the exception, but yet setting them would be allowed (because of prefetched foreign keys by default), then it would be great.

But here I wonder then, how would it work with partial objects? I.e. in

database.find(Order.class)
.fetch("name")
...
.findList();

I suppose only name is fetched, foreign keys aren't prefetched, so setting a ManyToOne field would do what? (and especially with ebean.disableLazyLoading = true?)

[rbygrave]

Background:
Reference entity beans are entity beans that only have their Id property set. We can explicitly create reference beans via Database#reference(Class<T> beanType, Object id). Reference beans exist in JPA, they are not an ebean only thing.

Reference beans are also created when we perform a query and return an object graph. Graph wise, reference beans are at the Leaves of the Tree/Object Graph.

For example, a query for Person that has a @ManyToOne Employer employer; ... when we get the Person entity bean, the employer property has a "Employer Reference Bean". This Employer bean only has the Id property populated, its value came from the person.employer_id foreign key column.

will work without prefetching old Employer, because Person actually had foreign key (to Employer) prefetched?

So:

// fetch a person entity ...
Person person = new QPerson().id.eq(1).findOne();

// the employer instance is a reference bean, only the Id property is populated 
Employer employer = person.getEmployer();

// lets update the employer property
Employer newEmployer = database.reference(Employer.class, 98);
person.setEmployer(newEmployer);

database.save(person);

The above is done without any join to the employer table, only the foreign key column person.employer_id was read, and then updated.

prefetched / non-prefetched relationships

I think these terms are not good ones to use in the ebean context because with ebean we can specify in the query what we are fetching and its a bit vague as to whether people are talking about using fetchType EAGER/LAZY relationship, reference beans, or populated beans.

Probably the thing to state explicitly is that we can fetch and set relationships like employer all using reference beans, they don't need any other properties to be populated etc.

how would it work with partial objects? ... select("name")

Only including the name property means that the foreign key column was not included so getEmployer() or setEmployer() is being called on a property that isn't loaded - and this works just the same as any other property that isn't loaded, no different to getStatus(), getDescription(), getWhenCreated().

So instead, select("name, employer") ... means the employer_id foreign key column would be included in the SQL select, and that the employer property would be loaded with a reference bean etc.

Note: Your example incorrectly used fetch() rather than select(). select() is for the "root level projection" and fetch() is for the "relationships projection" [which have options of fetch, fetchQuery, fetchCache, fetchLazy].

and especially with ebean.disableLazyLoading = true?

I think an issue here is we might need to go back a step and tell me what issue you have and what you are trying to achieve. I'm going to start another discussion specifically around Entity to Dto mapping and lazy loading so maybe that will address this question but it might not.