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.

[artpaym]

@rob-bygrave thanks for quick reply!

I'm curious what this new concept you're working on, would you able to share more why full immutability is seen as a benefit in the context of entity objects? How would users set fields in this case? I'm worried also this way the persistence library would force users` business logic to handle immutability as well?

Regarding this:

Throw an exception when we try to mutate them [like call setters]

why would it be a benefit? Instead, it seems fine to be setting a field even if it wasn't loaded, because it means the user doesn't care what value was inside previously, i.e. it's just unconditionally updating it. But maybe such approach somehow ties to the bigger picture of fully immutable objects you mentioned. Would you able to clarify?

[rbygrave]

why full immutability is seen as a benefit in the context of entity objects?

It's aiming for the read only case. If we want to fetch some entity beans and then mutate them we would not use this feature and just do what we do currently using normal mutable entity beans.

Once we have fully immutable entity beans we can be certain that they can be shared / cached in bean form [we know they can't be mutated by setters or lazy loading etc]. We can potentially use this as an alternative to the current L2 caching approach.

For example, ebean query language has fetchCache() and this could use a cache of immutable entity beans [rather than the current approach of "copies" of the cached "data"]. We can think of an ORM query as "Graph Building" and some of that graph can come from a cache of "fully immutable entity beans".

it seems fine to be setting a field even if it wasn't loaded, because it means the user doesn't care what value was inside previously

We can desire to know the "old value" in order to support features like change log, so we need to be careful if we ever supported something like that.

[artpaym]

@rob-bygrave

Thanks. Even for mutable entities (i.e. what we have nowadays), when lazy loading is disabled, it seems a useful option to throw exceptions instead of returning nulls? Will you consider this option in future separately from the immutability idea (which would be quite big context on its own I suppose)?

[rbygrave]

useful option to throw exceptions instead of returning nulls? Will you consider this option in future separately from the immutability idea

Yes I think we will consider it. Ultimately it might look wrong and inconsistent with the immutable idea.

If you have some good use case / arguments for changing it to throw, feel free to add that here.

Note that the "unmodifiable" idea has started at: #3570

[artemik]

The advantage of throwing is obviously to prevent cases where users access a not-loaded field (which would be "null") and wrongly think it's real "null" and therefore then make incorrect decisions based on that.

I like existing behavior with "nulls" because it allows transparent conversion of entities into DTOs on web layer, or easy toString() implementation (generated by Lombok, for example), and it also feels a bit less coupled to persistence layer. But at the same time the above case is still worrying.

If there would be a way to enable exceptions but also allow an easy way of checking if a field was loaded (for DTO conversions, toString(), etc), then I'd maybe choose such option.

Thoughts?