Sorry to take so freaking long to answer this. I was thinking on Henry's solution i.e. hard code the default parameter in an "abstract implementation" of the specific tests, and say that if someone wants to modify these tests, then it should do it without updating the hard coded value. This is only for testing purposes of course. This being said, we could even create two tests, one for inclusive and another one for exclusive keys.
Renato M. 2013/8/31 Henry Saputra <henry.sapu...@gmail.com> > We could just hard coded the default in the DataStore implementation. This > should not be changed via properties value I believe. > > - Henry > > > On Fri, Aug 23, 2013 at 10:41 AM, Apostolis Giannakidis < > ap.giannaki...@gmail.com> wrote: > > > Sure, > > but based on which value will we set the parameter? It should be a > > datastore specific value; i.e. each data store should set its own value > for > > this parameter. This is why I proposed to put it in the gora.properties > > file, as this will be configurable for each data store. This will serve > as > > the default case of the range. > > Additionally, we can provide extended API methods (as Renato suggested) > > that accept an extra argument that will override the default case. What > do > > you think? > > > > Apos > > > > > > On Fri, Aug 23, 2013 at 6:33 PM, Renato Marroquín Mogrovejo < > > renatoj.marroq...@gmail.com> wrote: > > > > > We'd have to set the new parameter before we start that specific test. > > Does > > > it make sense? > > > > > > > > > Renato M. > > > > > > > > > 2013/8/22 Apostolis Giannakidis <ap.giannaki...@gmail.com> > > > > > > > Oracle can have both inclusive and exclusive ranges. > > > > However, I still have not understood how the test cast will work, if > we > > > > follow Renato's suggestion to add another parameter to the API > method. > > > > > > > > Regards, > > > > Apos > > > > > > > > > > > > On Fri, Aug 23, 2013 at 2:16 AM, Henry Saputra < > > henry.sapu...@gmail.com > > > > >wrote: > > > > > > > > > +1 > > > > > > > > > > Looks like HBase is the one exception? Oracle and Accumulo seem to > be > > > > > inclusive, and I believe Cassandra also inclusive. > > > > > > > > > > In the DataStoreTestUtil, we could probably check the type of data > > > store > > > > > before executing the delete to pass the right flag. > > > > > > > > > > - Henry > > > > > > > > > > > > > > > On Thu, Aug 22, 2013 at 3:54 PM, Renato Marroquín Mogrovejo < > > > > > renatoj.marroq...@gmail.com> wrote: > > > > > > > > > > > @Henry, you are right mate (: > > > > > > @Apos, you are right as well mate (: but IMHO we could set this > > value > > > > > with > > > > > > a default value (the one that most data stores use) and run the > > tests > > > > > like > > > > > > this i.e. modifying the tests to make this run well, maybe we > could > > > > even > > > > > > set this new parameter when starting the test so it runs > smoothly. > > > > > > > > > > > > > > > > > > Renato M. > > > > > > > > > > > > > > > > > > 2013/8/22 Apostolis Giannakidis <ap.giannaki...@gmail.com> > > > > > > > > > > > > > Hi Henry, > > > > > > > > > > > > > > As far as I have understood Renato's proposal, that's correct. > > > > > > > But, now that I think of it, if we follow Renato's suggestion, > > then > > > > how > > > > > > > will the test case[1] know if it should include the key or not > in > > > its > > > > > > > checks? > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/gora/blob/trunk/gora-core/src/test/java/org/apache/gora/store/DataStoreTestUtil.java#L747 > > > > > > > > > > > > > > > > > > > > > On Thu, Aug 22, 2013 at 8:08 PM, Henry Saputra < > > > > > henry.sapu...@gmail.com > > > > > > > >wrote: > > > > > > > > > > > > > > > HI Renato, > > > > > > > > > > > > > > > > If the API change include a new parameter to indicate > inclusive > > > vs > > > > > > > > exclusive then Gora do not have to decide anything and just > > > > delegate > > > > > > the > > > > > > > > new parameter to the corresponding datastore? > > > > > > > > > > > > > > > > - Henry > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Aug 22, 2013 at 10:43 AM, Renato Marroquín Mogrovejo > < > > > > > > > > renatoj.marroq...@gmail.com> wrote: > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > I think we could just add an extra parameter to the query > > API, > > > so > > > > > > users > > > > > > > > can > > > > > > > > > decide programmatically whether they want to use the > deletes > > as > > > > > > > inclusive > > > > > > > > > or exclusive, and they could do this while programming with > > > > Gora's > > > > > > API. > > > > > > > > And > > > > > > > > > we could decide to use a default value for the option that > > most > > > > > data > > > > > > > > stores > > > > > > > > > support. What do you think? > > > > > > > > > > > > > > > > > > > > > > > > > > > Renato M. > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/8/18 Apostolis Giannakidis <ap.giannaki...@gmail.com> > > > > > > > > > > > > > > > > > > > Yes, I can also do both inclusive and exclusive ranges in > > > > Oracle > > > > > > > NoSQL. > > > > > > > > > So > > > > > > > > > > it remains to be decided by the Gora API. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Aug 18, 2013 at 4:06 AM, Scott Stults < > > > > > > > > > > sstu...@opensourceconnections.com> wrote: > > > > > > > > > > > > > > > > > > > > > Thanks for the reply, Apos. Seeing as how this test is > in > > > > flux > > > > > I > > > > > > > > won't > > > > > > > > > > > worry too much about it now. FWIW, I could do inclusive > > or > > > > > > > exclusive > > > > > > > > > > ranges > > > > > > > > > > > with Lucene. > > > > > > > > > > > > > > > > > > > > > > -Scott > > > > > > > > > > > > > > > > > > > > > > On Aug 17, 2013, at 9:52 PM, Apostolis Giannakidis < > > > > > > > > > > > ap.giannaki...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > Hello Scott, > > > > > > > > > > > > > > > > > > > > > > > > The issue that you just spotted is the same issue > that > > I > > > > also > > > > > > > > > > > > coincidentally spotted a week ago. > > > > > > > > > > > > Keith Turner first identified the issue and > documented > > it > > > > in > > > > > > > Jira. > > > > > > > > > > Please > > > > > > > > > > > > see GORA-66. > > > > > > > > > > > > https://issues.apache.org/jira/browse/GORA-66 > > > > > > > > > > > > > > > > > > > > > > > > This is also a blocking issue for me, as it does not > > > allow > > > > me > > > > > > to > > > > > > > > > > complete > > > > > > > > > > > > the implementation of deleteByQuery(). Personally, I > > > > @Ignored > > > > > > > this > > > > > > > > > test > > > > > > > > > > > > case until GORA-66 is resolved. I saw that the same > was > > > > done > > > > > in > > > > > > > > > > Accumulo > > > > > > > > > > > > datastore. > > > > > > > > > > > > > > > > > > > > > > > > I hope this helps, > > > > > > > > > > > > Apos > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 17, 2013 at 8:11 PM, Scott Stults < > > > > > > > > > > > > sstu...@opensourceconnections.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > >> All, > > > > > > > > > > > >> > > > > > > > > > > > >> I'm having a little trouble getting my head around > > > > > > > > deleteByQuery(). > > > > > > > > > > The > > > > > > > > > > > >> javadoc in the interface indicates that any object > > that > > > > > > matches > > > > > > > > the > > > > > > > > > > > query > > > > > > > > > > > >> should get deleted. The unit test > > > > > > > > > > > >> DataStoreTestUtil.testDeleteByQueryFields() expects > > the > > > > > object > > > > > > > to > > > > > > > > > > still > > > > > > > > > > > >> exist with the queried-for fields cleared. To me it > > > seems > > > > > like > > > > > > > the > > > > > > > > > > test > > > > > > > > > > > is > > > > > > > > > > > >> for an update, rather than a delete. > > > > > > > > > > > >> > > > > > > > > > > > >> Are my semantics all mixed up? > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> Thanks, > > > > > > > > > > > >> -Scott > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
