Hey Renato, Sure, ok. I agree with you. I can try to have a patch ready for this, if others agree too.
Cheers, Apos On Thu, Aug 22, 2013 at 6:59 PM, Renato Marroquín Mogrovejo < renatoj.marroq...@gmail.com> wrote: > 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 > > > > > >> > > > > > > > > > > > > > > > > > > > >
