Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updatable entity view prototype #414

Closed
beikov opened this issue Apr 26, 2017 · 1 comment

Comments

@beikov
Copy link
Member

commented Apr 26, 2017

We have an extensive feature list provided in #127 and we should prototype some of the features so we can test them in real applications. It is not a goal to implement all features in this release but get a minimal version that can be used and actually makes sense. We should focus on the features rather than the best implementation or various strategies to see if this model is actually usable in real applications or how it should be adapted.

@beikov beikov added this to the 1.2.0 milestone Apr 26, 2017

@beikov beikov self-assigned this Apr 26, 2017

@beikov beikov added this to TODO in 1.2.0.Alpha4 Apr 26, 2017

@beikov beikov moved this from TODO to In Progress in 1.2.0.Alpha4 Apr 28, 2017

beikov added a commit to beikov/blaze-persistence that referenced this issue May 3, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue May 19, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue May 24, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue May 31, 2017
@beikov

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2017

During the discussion with some of my fellow colleagues, we thought through some questions that came to my mind.

Should we support only managed i.e. created via factory, or also instances of custom subtypes

At first, only allow managed instances, in a final version we might also allow custom subtypes for easier integration

Do we want a special designation of create models i.e. models that are used for creating entities?

Yes we want that(@CreatableEntityView) and also the "completeness" validation that can be done because of the special designation. It should be possible to disable validation for certain attributes that might be set in listeners. Updatable views should also be usable to create new instances, although this behavior should be configurable.

Where should generated ids be set?

Set the value on the respective objects. Note that this requires such views to have an id mapping just like updatable entity views, although it doesn't have to be updatable.

How should cascading and subtypes be handled when having updatable/non-updatable mutable types?

We decided on the defaults

  • Allowed subtypes must be declared. If a not allowed subtype is encountered, an exception is thrown.
  • Updatable mappings will only cascade UPDATE by default, when the static type is an updatable view.
  • Updatable mappings will only cascade PERSIST by default, when the static type is a creatable view.
  • Mutable mappings will cascade UPDATE by default.
  • Non-Updatable collection mappings of non-mutable types will not cascade anything by default.
  • Non-Updatable collection mappings of mutable types will cascade UPDATE by default.
  • Non-Updatable mappings will never change the entity relation representing it i.e. no "collection add".

What update and flush strategies should be supported?

Currently we have the partial strategy, which does dirty checking and skips updates of non-dirty attributes and the full strategy, which always updates everything.
The full strategy has a better query cache hit ratio, but might involve higher data transfer.
The partial strategy has better data transfer characteristics, but is a bit more complicated to compute and has a bad query cache hit ratio.
We decided that although both strategies have valid use cases, we'd like a hybrid of the two strategies as new default. The default strategy should still be configurable on the @UpdatableEntityView annotation.

The new strategy will do dirty checking like the partial strategy and will do a full update of the object, if at least one attribute is dirty. By doing the dirty checking, the strategy can implement entity graph loading or query flushing more efficiently.

What should the "updateFull" method do when subviews have partial updating configured?

Should ignore the configured default and do full updates all the way.

Bi-Directional mapping optimizations

When mapping a collection in an entity view that has a inverse relation mapping, the "collection add/remove" operations can be implemented by updating the inverse relations respectively. This is a nice optimization that should be implemented at some point.

Do we really need access to dirty state?

After discussing possible use cases like auditing or conditional checks, we decided that this is a very important feature. Maybe we could even annotate a lock level or so that should be used when a change is detected.

Other features we discussed

  • Listeners for "pre-load", "pre-persist" and "pre-update" events
  • Entity views without a root i.e. aggregates of multiple roots
beikov added a commit to beikov/blaze-persistence that referenced this issue Jun 20, 2017
Blazebit#414 - Implemented subtype checking, cascading for updatable …
…entity views and a notion for creatable entity view
beikov added a commit to beikov/blaze-persistence that referenced this issue Jun 20, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jun 20, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jun 20, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 18, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 18, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 18, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 18, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 18, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 18, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 23, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 23, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 23, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 26, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 26, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 26, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 26, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 27, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Jul 27, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 3, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 3, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 4, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 5, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 5, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 5, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 6, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 6, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 6, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 6, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 6, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 6, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 6, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 6, 2017

@beikov beikov moved this from In Progress to Done in 1.2.0.Alpha4 Nov 6, 2017

beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 6, 2017
beikov added a commit that referenced this issue Nov 6, 2017
beikov added a commit that referenced this issue Nov 6, 2017
beikov added a commit that referenced this issue Nov 6, 2017
beikov added a commit that referenced this issue Nov 6, 2017

@beikov beikov closed this Nov 6, 2017

beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 9, 2017
beikov added a commit that referenced this issue Nov 10, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 12, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 22, 2017
Blazebit#414 - Fixed changemodel and view to entity mappers regarding…
… immutable types. Added Plural factories as preparation for collection remappings and to allow sorted variation in edit views. Fixed Blazebit#476 by replacing objects in hash based collections after persists.
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 23, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Nov 24, 2017
beikov added a commit to beikov/blaze-persistence that referenced this issue Dec 12, 2017
[Blazebit#414] Handle non-Java EE JTA environments and skip updater r…
…elated entity view updater initialization for read-only views
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
1 participant
You can’t perform that action at this time.