Without knowing anything about Lucene, given the fact that most RDBMS support full-text search, couldn't we just use the database for such searches as a stopgap?
Nick >> -----Original Message----- >> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, January 20, 2004 12:35 PM >> To: Slide Developers Mailing List >> Subject: Re: Proposal : index store - Lucene >> >> >> >> On 20 Jan 2004, at 11:27, Wallmer, Martin wrote: >> >> > >> > -----Original Message----- >> > From: Michael Oliver [mailto:[EMAIL PROTECTED] >> > Sent: Montag, 19. Januar 2004 15:13 >> > To: Slide Developers Mailing List >> > Subject: Re: Proposal : index store - Lucene >> > >> > >> > On Mon, 2004-01-19 at 06:32, Stefano Mazzocchi wrote: >> > >> >> On 18 Jan 2004, at 22:12, Christophe wrote: >> >> >> >>> Stefano Mazzocchi wrote: >> >>> >> >>>> >> >>>> >> >>>>> If you store your properties in one store (eg. DB) and >> used index >> >>>>> store engine for content search, I expected to have some >> >>>>> performance issues when you search on prop and content. >> >>>> >> >>>> >> >>>> hmmm, not sure I follow you, can you elaborate on this more? it >> >>>> would >> >>>> be very appreciated. >> >>>> >> >>> How do you make a query that used criteria on properties >> and full >> >>> text >> >>> search? >> >> >> >> eh, good question :-) >> > >> > Using DASL this is streightforward: >> >> my smile was based not the lack of syntax to define this, >> but on making >> this natural and scalable. >> >> > a query that gets all documents of content type >> "text/plain" bytes and >> > containing the string "jakarta" could be posed as: >> > >> > <?xml version="1.0" encoding="UTF-8"?> >> > <searchrequest xmlns:D="DAV:" >> > xmlns:xsv="http://namespaces.softwareag.com/tamino/webdav">> >> > <D:basicsearch> >> > <D:select> >> > <D:allprop/> >> > </D:select> >> > <D:from> >> > <D:scope> >> > <D:href>mycoll</D:href> >> > </D:scope> >> > </D:from> >> > <D:where> >> > <D:and> >> > <D:eq> >> > <D:prop> >> > <D:getcontenttype/> >> > </D:prop> >> > <D:literal>text/plain</D:literal> >> > </D:eq> >> > <D:contains>jakarta</D:contains> >> > </D:and> >> > </D:where> >> > </D:basicsearch> >> > </searchrequest> >> > >> > A Full text search on properties can be achieved with the operator >> > <LIKE> >> >> Would you suggest that we somehow differentiate basic-search queries >> and run them thru different engines depending on the nature of the >> query? [curious] >> >> This is an alternative scenario respect to providing another >> DASL query >> language for specific for full-text and associating the query engine >> with the language used, not with the type of query in a particular >> language. >> >> What do others think about this? >> >> -- >> Stefano. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
