Hi Srinath, Thanks for the reply. Yes, the original question was to discuss whether we should use the originally expected query as is or to define a simpler syntax and create the complex query that is expected by the attribute search service internally. Given a query country=usa, we can internally look for both attributes and properties. But how would someone search for tags and comments? In that case, should the user be sending the query tags=<tag value> and comment=<Comment>?
@Isuruwan : Currently we can't use the search with & of two properties even with the map as it's obvious that there can be only one key (say propertyName) in a map. @Nuwan : The values can be checked for both. In that case the rightPropertyValue=usa OR lk @Anjana : Currently, our search service internally builds the solr query and that service expects the complex query as mentioned above. We can solr query to be passed directly (which again is a discussion on whether we should allow the user to search all attributes indexed as you have mentioned). But IMO, it would be best to define a simple query and we build the expected query internally. @Sagara/Ruchira/Danesh : Shall we discuss this further f2f? Shazni Nazeer Mob : +94 777737331 LinkedIn : http://lk.linkedin.com/in/shazninazeer Blog : http://shazninazeer.blogspot.com On Mon, May 25, 2015 at 10:18 AM, Anjana Fernando <[email protected]> wrote: > Hi, > > Yeah, we simply use the Lucene query syntax. There was no reason for us to > create our own on top of it, because it provides a very powerful syntax to > query the data. For example, Elastic also use Lucene query language for > there solution. I'm not sure, for registry if this is suitable or not, as > in, by giving the full power to the user to query all the attributes > indexed, and whether some should be filtered/hidden from the end user. > > Cheers, > Anjana. > > On Mon, May 25, 2015 at 8:53 AM, Srinath Perera <[email protected]> wrote: > >> Shazni, is backend our code? if so we can fix it. Or we can translate >> from simpler version to complex version automatically in our code. I also >> think it should be country=usa. >> >> Also, BAM had the same problem and gone with Solr syntax. I am not sure >> what is the right answer, but pretty use it should be same for both. >> Sagara, Anjana please talk. >> >> --Srinath >> >> >> >> On Fri, May 22, 2015 at 5:58 PM, Shazni Nazeer <[email protected]> wrote: >> >>> @Manuranga - Fair question. But that's the way the search attribute >>> service in the backend expects. Further, the query I have given is >>> specifically to query a property in the artifact. So specifying >>> "country=usa", we should internally find out that it's a property that the >>> user is querying. And for your concern that "convenient method is not that >>> convenient", that's what the question is all about; whether to keep the >>> query as it's or use a different syntax and pass the attribute map to the >>> search service within the method. >>> >>> Shazni Nazeer >>> Mob : +94 777737331 >>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>> Blog : http://shazninazeer.blogspot.com >>> >>> On Fri, May 22, 2015 at 5:29 PM, Manuranga Perera <[email protected]> wrote: >>> >>>> That convenient method is not that convenient. >>>> >>>> Why >>>> "propertyName=country&rightOp=eq&rightPropertyValue=usa" >>>> Instead >>>> "country=usa" >>>> ? >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> http://people.apache.org/~hemapani/ >> http://srinathsview.blogspot.com/ >> > > > > -- > *Anjana Fernando* > Senior Technical Lead > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
