Hi Shazni, While integrating the new search API to the ES I have encountered an issue with the following search syntax:
overview:name=wso2 Any search queries with this syntax will need to be URL encoded when invoked with the ES /assets API: /apis/assets?type=gadget&q="overview:name"="wso2" The syntax for searching should be consistent across both the UI and API. Thus is it possible for the provided API to be altered to conform to the _ convention? Thank You, Sameera Thank You, Sameera On Thu, Jun 4, 2015 at 5:30 PM, Shazni Nazeer <[email protected]> wrote: > Hi Ruchira, > > Find my answers inline. > > - Each RXT must have a table named "overview" > > It's not a necessity. However, when someone specifies only a name like > xyz, it searches for overview_name, meaning it looks under the rxt table > called 'overview'. > > - There can't be any RXT which has tags, lcState, lcName, mediaType as > fields under overview table. i.e. overview_tags or overview_lcState > shouldn't be there and those are considered as keywords? > > Yes, these are keywords. These can still be under a table, in which case > they'll have to specifically search as below concern. > > - What will happen when there are tables other than overview, did you > implement colon separator as discussed? i.e. If you have a table named > *company* which has a *name* under it, then it can be searched via > *company:name=WSO2* > > Yes. This is implemented as we discussed off line. > > - What happens with the properties that you use internally, such as > the property being used to mark the default asset etc. Will they also get > listed when a search query has any matching words? > > Say we have a property, called 'default' with value 'true'. If someone > searches with a query default=true, those artifacts will be returned. > > Shazni Nazeer > Mob : +94 777737331 > LinkedIn : http://lk.linkedin.com/in/shazninazeer > Blog : http://shazninazeer.blogspot.com > > On Thu, Jun 4, 2015 at 2:44 PM, Ruchira Wageesha <[email protected]> wrote: > >> >> >> On Wed, May 27, 2015 at 3:45 PM, Shazni Nazeer <[email protected]> wrote: >> >>> With regard to above discussions I implemented a method to take a query >>> string and internally handle the intricacies of expected parameter map with >>> expected keys. This method also utilizes the existing >>> findGovernanceArtifacts. The method processes the query and parses it to >>> pass the parameter map. Following are few examples of the query. >>> >>> 1. xyz - Looks for artifacts with name xyz >>> 2. xyz&version=1.3.5 - Looks for artifacts with name xyz with version >>> 1.3.5 >>> 3. tags=abc - Searches artifacts with tag 'abc' >>> 4. lcState=development&lcName=ServiceLifeCycle - Searches artifacts with >>> an associated life cycle name ServiceLifeCycle with state 'development' >>> 5. country=usa - Looks for all the artifacts having attribute country >>> with value 'usa'. This internally handles whether country is an rxt >>> attribute or a property. >>> 6. version=1.3.5&mediaType=application/vnd.wso2-soap-service+xml - >>> searches only soap services with version 1.3.5 >>> >>> The resulted artifacts are returned as GovernanceArtifacts in a list. >>> From ES end, if we can have a search box or a place for user to type >>> queries and get the result and display, the search requirement in the >>> publisher/store would be fulfilled. >>> >> We can implement a search callback, where you can get the control of >> search based on asset type. >> >> I have the following concern regarding the search syntax, which you might >> be able to clarify more. >> >> - Each RXT must have a table named "overview" >> - There can't be any RXT which has tags, lcState, lcName, mediaType >> as fields under overview table. i.e. overview_tags or overview_lcState >> shouldn't be there and those are considered as keywords? >> - What will happen when there are tables other than overview, did you >> implement colon separator as discussed? i.e. If you have a table named >> *company* which has a *name* under it, then it can be searched via >> *company:name=WSO2* >> - What happens with the properties that you use internally, such as >> the property being used to mark the default asset etc. Will they also get >> listed when a search query has any matching words? >> >> /Ruchira >> >>> >>> >> Shazni Nazeer >>> Mob : +94 777737331 >>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>> Blog : http://shazninazeer.blogspot.com >>> >>> On Wed, May 27, 2015 at 9:56 AM, Shazni Nazeer <[email protected]> wrote: >>> >>>> Hi Isuruwan, >>>> >>>> Yes we can do combination of search attributes using >>>> findGovernanceArtifacts. What we can't do is, searching for multiple >>>> properties. Say we have two properties in a service instance. We can't use >>>> the findGovernanceArtifacts method to find artifacts having both the >>>> properties. >>>> >>>> Shazni Nazeer >>>> Mob : +94 777737331 >>>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>>> Blog : http://shazninazeer.blogspot.com >>>> >>>> On Wed, May 27, 2015 at 1:49 AM, Isuruwan Herath <[email protected]> >>>> wrote: >>>> >>>>> Hi Shazni, >>>>> >>>>> On Mon, May 25, 2015 at 12:38 AM, Shazni Nazeer <[email protected]> >>>>> wrote: >>>>> >>>>>> 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. >>>>>> >>>>> >>>>> Not related to original topic but, I believe we can do combination of >>>>> search attributes using findGenericArtifacts as shown in this sample [1]. >>>>> What I meant was a similar combination. >>>>> >>>>> [1] >>>>> https://docs.wso2.com/display/Governance460/Governance+Artifact+Search+Sample >>>>> >>>>> Thanks! >>>>> Isuruwan >>>>> >>>>>> @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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Isuruwan Herath >>>>> Technical Lead >>>>> >>>>> Contact: +94 776 273 296 >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> >> >> -- >> >> *Ruchira Wageesha**Technical Lead* >> *WSO2 Inc. - lean . enterprise . middleware | wso2.com <http://wso2.com>* >> >> *email: [email protected] <[email protected]>, blog: >> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, >> mobile: +94 77 5493444 <%2B94%2077%205493444>* >> >> _______________________________________________ >> 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 > > -- Sameera Medagammaddegedara Software Engineer Contact: Email: [email protected] Mobile: + 94 077 255 3005
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
