> On Feb. 21, 2017, 11:38 p.m., Vadim Spector wrote: > > sentry-service/sentry-service-server/src/main/java/org/apache/sentry/provider/db/service/persistent/QueryParamBuilder.java, > > line 65 > > <https://reviews.apache.org/r/56481/diff/2/?file=1640442#file1640442line65> > > > > So, in this implementation one parameter name can only appear once in > > the entire query. Otherwise, the key-value pair in the "arguments" will be > > overwritten (and the client code won't even know it). > > > > This is because the query is formed as > > > > queryPart = fieldName + " == " + ":" + fieldName; > > arguments.put(fieldName, fieldValue). > > > > Instead, we could use AtomicInteger count, shared by parent > > QueryParameterBuilder and all of it children (just like all children share > > "arguments" now) to do this: > > > > valueToken = ":value_" + count.incrementAndGet(); > > queryPart = fieldName + " == :" + valueToken; > > arguments.put(valueToken, fieldValue); > > > > Or am I missing something? If there is a reason not to support the same > > field appearing in the query more than once, it needs to be documented and > > an exception should be thrown when someone tries to override an existing > > entry in "arguments". > > Vadim Spector wrote: > typo: should be > valueToken = "value_" + count.incrementAndGet(); > since ":" already appears in queryPart expression. > > Alexander Kolbasov wrote: > It is possible to make names unique - in fact, we do it in case of roles > filter. We do not have a use case for that and it will make inspection of > args a bit ugly, but this could be ok. We don't need to use atomics - the > whole thing isn't thread-safe. If you think that it is important to support > same-name params, I'll add the code to do it. This will make testing trickier > since I test for keys and values and it is difficult to guarantee specific > generated names. > > Vadim Spector wrote: > I'm worried that nothing stops the client of this class from using it > incorrectly. Having the key-value pair overwritten leads to hard-to-debug > errors, so throwing an exception when arguments.put(key,value) != null would > be one obvious solution. However, it would make QueryParameterBuilder of > limited value, while it can be easily made a generic query builder. > > Alexander Kolbasov wrote: > The problem is that your suggestion will replace one kind of subtle > errors for another kind of subtle errors. If I supplied the same name by > mistake, generating unique names will add it incorrectly where the original > approach will drop one of them - and both are wrong. The right thing would be > to throw exception. I'll add an exception for this case. > > Vadim Spector wrote: > ... we need the parent builder and all of its descendants to share the > same count, so thread-safe or not, AtomicInteger does the job with minoimal > overhead. We cannot share "int" because it's not passed by reference - unless > we invent a mutable wrapper class. Or make each child point at the top > parent, whoch is messy. > > Vadim Spector wrote: > I'm not sure how it introduces more errors - if we want this class to > qualify as general-purpose query builder, it must support queries where the > same field participates more than once. It's very common in general-purpose > queries. Unless we are really sure that in our specific use case it will > never be needed.
In this case we may want to distinguish between "I am providing the name and I know what I am doing" vs "please choose the unique name for me". I'll see whether we can provide the second one as well. - Alexander ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/56481/#review166266 ----------------------------------------------------------- On Feb. 20, 2017, 5:46 a.m., Alexander Kolbasov wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/56481/ > ----------------------------------------------------------- > > (Updated Feb. 20, 2017, 5:46 a.m.) > > > Review request for sentry, Hao Hao, kalyan kumar kalvagadda, Sergio Pena, > Vamsee Yarlagadda, and Vadim Spector. > > > Bugs: SENTRY-1625 > https://issues.apache.org/jira/browse/SENTRY-1625 > > > Repository: sentry > > > Description > ------- > > SENTRY-1625: PrivilegeOperatePersistence can use QueryParamBuilder > > > Diffs > ----- > > > sentry-service/sentry-service-server/src/main/java/org/apache/sentry/provider/db/generic/service/persistent/PrivilegeOperatePersistence.java > b1180bff1ce8850712e842e59e0e7217273ac59c > > sentry-service/sentry-service-server/src/main/java/org/apache/sentry/provider/db/service/model/MSentryGMPrivilege.java > 55b61ac07c6865402ffe4d0ff1690afb435deb95 > > sentry-service/sentry-service-server/src/main/java/org/apache/sentry/provider/db/service/persistent/QueryParamBuilder.java > PRE-CREATION > > sentry-service/sentry-service-server/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java > 7b926a5e546091881d4f7b4f30df4ae82dcd35b0 > > sentry-service/sentry-service-server/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java > 17a4a937221891a72ee44db92976cfa5cab40bc4 > > Diff: https://reviews.apache.org/r/56481/diff/ > > > Testing > ------- > > > Thanks, > > Alexander Kolbasov > >
