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

Issue/refactor path extension #1526

Closed
wants to merge 7 commits into from
Closed

Conversation

schauder
Copy link
Contributor

@schauder schauder commented Jun 1, 2023

AggregatePath replaces PersistentPropertyPathExtension.
It gets created and cached by the RelationalMappingContext, which should be more efficient and certainly looks nicer.

Closes #1525

@schauder schauder requested a review from mp911de June 1, 2023 14:38
Copy link
Member

@mp911de mp911de left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the direction of the changes. They start reflecting the underlying metamodel. I added a few initial comments. The column and table handling of paths is coupled to tight effectively preventing certain use-cases when using embedded property holders. Also, there are some aspects that require further refinement in the sense of methods allowing traversal.

Commonly used functionality should go into utilities so that with the known requirements (e.g. composite primary keys) we do not need to break our API but rather keep a clear separation between concerns.

* @since 3.2
* @author Jens Schauder
*/
public class AggregatePath {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's extract AggregatePath as interface with the default implementation being package-private, similar to PersistentPropertyPath.

/**
* @return {@literal true} if this path represents an entity which has an Id attribute.
*/
public boolean hasIdProperty() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This property can be checked directly from getLeafEntity(). A path should conceptually not have an identifier property.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really follow. What makes this different than the other boolean properties?

*
* @return A path that starts just as this path but is shorter. Guaranteed to be not {@literal null}.
*/
public AggregatePath getIdDefiningParentPath() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be neat to refactor this method to a path-traversal method to walk the path hierarchy with a Predicate. The concrete functionality here would fit into a utility as paths should not be tied to identifiers.


if (path.getLength() == 1) {
Assert.notNull(prefix, "Prefix mus not be null");
return StringUtils.hasText(prefix) ? SqlIdentifier.quoted(prefix) : null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should honor quoting settings of the underlying table and property.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree. This is for aliases only. They are only used internally in SQL statements.

*
* @return a path. Guaranteed to be not {@literal null}.
*/
private AggregatePath getTableOwningAncestor() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is another indication of the need to traverse the AggregatePath hierarchy with having an utility for querying the model.


Assert.state(path != null, "Path is null");

return assembleColumnName(path.getLeafProperty().getColumnName());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how this remains applicable for properties that reference an embedded holder (embedded properties object, composite Id class) as these map to multiple inner columns. (e.g. person.address where address is class Address {String street; String zip;}.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path includes those embedded entities. Therefore the relevant paths would be address/street and address/zip.

assembleColumnName takes care of prefixing embedded property names appropriately.

AggregatePath replaces PersistentPropertyPathExtension.
It gets created and cached by the RelationalMappingContext, which should be more efficient and certainly looks nicer.

Closes #1525
@schauder schauder force-pushed the issue/refactor-path-extension branch from 45c55c3 to 86b090d Compare June 13, 2023 13:20
Using isRoot() instead of path == null.
Rename extendBy to append.
Move getRequiredLeafEntity closer to getLeafEntity.
Replace matches with equals.
This forces us to make some methods public, that have been private before.
@schauder schauder force-pushed the issue/refactor-path-extension branch from 86b090d to cb890c5 Compare June 13, 2023 13:23
Introduce accessor and detector utilities to discover columns. Introduce ForeignTableDetector to make the concept of owning and reference explicit.
@schauder
Copy link
Contributor Author

After heavy reworking we resolved this by merging d00e928

@schauder schauder closed this Jul 21, 2023
@schauder schauder deleted the issue/refactor-path-extension branch September 15, 2023 13:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor PersistentPropertyPathExtension
2 participants