-
Notifications
You must be signed in to change notification settings - Fork 199
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
Move inner classes to standalone classes #1095
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally seems like a good direction to extract all the Result classes. I don't mind too much which package, but should BaseResult
be in the same package?
import org.apache.polaris.core.persistence.BaseResult; | ||
|
||
/** a set of returned entities result */ | ||
public class EntitiesResult extends BaseResult { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to keep BaseResult
in the persistence
package when all the subclasses are moved in here, or should BaseResult
also be moved here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imho, it should also be in the persistence package to be really isolated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved BaseResult
to the same package. It's under the persistence package already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 it looks better, thanks !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This refactoring LGTM overall, just one minor comment.
import org.apache.polaris.core.entity.PolarisEntity; | ||
import org.apache.polaris.core.entity.PolarisEntityCore; | ||
import org.apache.polaris.core.entity.PolarisEntityId; | ||
import org.apache.polaris.core.entity.PolarisEntitySubType; | ||
import org.apache.polaris.core.entity.PolarisEntityType; | ||
import org.apache.polaris.core.entity.PolarisGrantRecord; | ||
import org.apache.polaris.core.entity.PolarisPrincipalSecrets; | ||
import org.apache.polaris.core.persistence.dao.entity.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please expand to individual imports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make spotless check for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the star import.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, we can add a file with something like this in it
<module name="AvoidStarImport"/>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like spotless cannot do that, we will need a new plugin like this
pluginManager.withPlugin('com.palantir.baseline-checkstyle') {
checkstyle {
toolVersion '9.3'
}
}
.../src/main/java/org/apache/polaris/core/persistence/TransactionWorkspaceMetaStoreManager.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as well !
@@ -51,6 +51,7 @@ | |||
import org.apache.polaris.core.entity.PolarisPrivilege; | |||
import org.apache.polaris.core.entity.PolarisTaskConstants; | |||
import org.apache.polaris.core.persistence.*; | |||
import org.apache.polaris.core.persistence.dao.entity.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just in this case this gets missed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
Fixed all star import introduced by this PR. Thanks @dimas-b and @singhpk234 for catching it. There are other places having star import as well. File #1100 to track it. |
import org.apache.polaris.core.entity.PolarisEntitySubType; | ||
|
||
/** the return for an entity lookup call */ | ||
public class EntityResult extends BaseResult { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Organizationally the change makes sense to me, but to my knowledge this is the first PR that adds the DAO / entity terminology -- potentially a little confusing when we have PolarisBaseEntity
and friends.
To clarify, what is going to be the scope of this new package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, just saw your message after merging. I was trying to position dao
to hold most interfaces, entity, util related to DAO layer. I'm open to any suggestions.
This PR extracts several inner classes of
PolarisMetastoreManager
into top-level classes, improving readability and maintainability. After the refactor, thePolarisMetastoreManager
interface now contains only methods, making it concise and clean. Typically, inner classes are used when their lifecycle depends on the outer class instance. However, these particular classes were independent, being used not only by service layers but also potentially by other database implementations. They are more suitable as top-level classes.