Hi Apos, I think your suggestion of making this configurable is the way to go. But if we make the property configurable through the config file, then if the user wants to change that programmatically, he'd need to reload the whole properties file? I mean if he first wants to do some queries exclusively, and then some others inclusively. I don't think reloading the properties file everytime would be less overhead than having an extra boolean variable inside our query API (about 1 byte more using Sun JVM).
Renato M. 2013/8/22 Apostolis Giannakidis <ap.giannaki...@gmail.com> > Hey Renato, > > I think that what you suggest would work. > However, since the value of the extra parameter will be the same for *all* > subsequent calls of the query method, then having an extra parameter is > just an extra overhead. I suggested to have a property in the > gora.properties to indicate if the range should be inclusive or exclusive. > https://issues.apache.org/jira/browse/GORA-66 > > Apos > > > > On Thu, Aug 22, 2013 at 6:43 PM, 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 > > > > >> > > > > > > > > > > > > > >
