You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a use case where we want to compare the trimmed contents of a database field with the trimmed contents of a provided value. In pseudo code:
WHERE TRIM({object:field}) = TRIM(?parameter1)
To support this use case while still being able to use your library, we created the following two classes:
package org.bitbucket.andriichukandrii.hybris.flexiblesearchbuilder;
import org.spockframework.util.Assert;
public class TrimmedField implements Field {
private final Field decorated;
public TrimmedField(Field decorated) {
Assert.notNull(decorated, "The parameter decorated can not be null.");
this.decorated = decorated;
}
@Override
public String getFieldName() {
return decorated.getFieldName();
}
@Override
public String toString() {
return "TRIM(" + decorated.toString() + ")";
}
}
We have to keep our extensions in the same package, because the parent classes contain protected methods.
We had to duplicate a lot of the code from the parent classes into our extensions to make it work
Perhaps a better way can be created to support both use cases? We saw classes called SqlFuntion and SqlFunctions. Adding TRIM there might be a good first step, but other places in the builder also need to be changed to accept and SqlFunction then. Changing some of the access modifiers to be less restrictive would also help users of the library to add extensions to it.
The text was updated successfully, but these errors were encountered:
The idea with the protected access was mostly to simplify usage/autocompletion and not for restricting the extension possibility of course. Initially I didn't add such functions to be platform-independent and follow only SQL standard. I need to rethink it probably.
We have a use case where we want to compare the trimmed contents of a database field with the trimmed contents of a provided value. In pseudo code:
To support this use case while still being able to use your library, we created the following two classes:
and
The way we made this work is not ideal however:
Perhaps a better way can be created to support both use cases? We saw classes called
SqlFuntion
andSqlFunctions
. AddingTRIM
there might be a good first step, but other places in the builder also need to be changed to accept and SqlFunction then. Changing some of the access modifiers to be less restrictive would also help users of the library to add extensions to it.The text was updated successfully, but these errors were encountered: