To expand on those answers by Justin and Geert: I've played with this challenge a bit about a year ago and come to an interesting solution that worked well enough for my needs:
- set up a trigger on update or insert - analyze the doc to see if it matches your function (the code you are using, for example) - store the uri in a document as a type of index if it matches. Consider it essentially a filtered verison of the URI lexicon I used one 'document' per 'filter' for various lexicons Sounds odd, but consider the following With the proper index, I can use element-values passed to a cts:document-query to create a filter completely from indexes. I also cheat a bit and use serialized maps. a bit of extra content, but then I can just use map-put and guarentee no duplicates. You could thin that our much more by checking for an element before Kind Regards, David Ennis David Ennis *Content Engineer* [image: HintTech] <http://www.hinttech.com/> Mastering the value of content creative | technology | content Delftechpark 37i 2628 XJ Delft The Netherlands T: +31 88 268 25 00 M: +31 63 091 72 80 [image: http://www.hinttech.com] <http://www.hinttech.com> <https://twitter.com/HintTech> <http://www.facebook.com/HintTech> <http://www.linkedin.com/company/HintTech> On 8 January 2015 at 21:27, Justin Makeig <[email protected]> wrote: > As Geert indicates, there is no exactly comparable functionality in > MarkLogic today. You can think of the document—structure and values—as the > "API to the indexes". Thus, if you want to index something it needs to be > (mostly) explicit in the document itself. (Word stemming is a counter > example of something that's automatically derived index time.) I think your > best bet will be to compute the derived values for inserts or updates and > batch process your existing content. You can use CPF < > http://docs.marklogic.com/guide/cpf> or lower level triggers < > http://docs.marklogic.com/guide/app-dev/triggers> to manage the > steady-state workflow or orchestrate externally depending on what you have > in front of MarkLogic (e.g. an application/service layer in Java, for > example). > > Justin > > > On Jan 8, 2015, at 12:19 PM, Geert Josten <[email protected]> > wrote: > > > > Hi Alexei, > > > > On the question whether MarkLogic allows indexing function results, then > the answer is unfortunately no. Such a feature is on the wish list of many > of us. > > > > The best alternative for upper-case would be using collations to ignore > case, for instance http://marklogic.com/collation//S1 (ignore case and > diacritics) or http://marklogic.com/collation//S2 (ignore case). You can > use the collation builder in the admin interface to tweak the collation > uri, or search the documentation to find out all options. > > > > Kind regards, > > Geert > > > > From: Alexei Betin <[email protected]> > > Reply-To: MarkLogic Developer Discussion < > [email protected]> > > Date: Thursday, January 8, 2015 at 8:47 PM > > To: "[email protected]" <[email protected]> > > Subject: [MarkLogic Dev General] function index in MarkLogic? > > > > Hello, > > > > > > > > Does MarkLogic has something similar to “function index” as exists in > other databases such as Oracle? For example, in Oraclecreate a function > index on a value of UPPER(<field_name>) as follows: > > > > CREATE INDEX cities_fn_idx ON cities (UPPER(name)); > > > > which ensures that a query like the one below is efficient and not using > the full table scan: > > > > SELECT name FROM cities WHERE UPPER(name) = 'HOUSTON'; > > > > > > > > I’d like to do something similar with MarkLogic which could help speed > up, e.g. the following simple query (which currently prohibitively slow > despite an index on /A/City): > > > > > > > > collection()/A/[upper-case( City ) = 'HOUSTON'] > > > > > > > > upper-case() is only an example, I am looking for a solution that would > accommodate any function/transformation that to be used in a query > condition from an existing element. > > > > > > > > Clearly, one solution would be to pre-compute the derived field, add it > to all the documents in the collection, and create an a “function index”). > > > > > > > > Thanks, > > > > > > > > <image005.jpg> > > <image006.jpg> > > Alexei Betin > > > > Principal Architect; Big Data > > P: (817) 928-1643 | Elevate.com > > 4150 International Plaza, Suite 300 > > Fort Worth, TX 76109 > > > > > > > > Privileged and Confidential. This e-mail, and any attachments thereto, > is intended only for use by the addressee(s) named herein and may contain > privilegedthereto, is strictly prohibited. > > > > > > > > > <image005.jpg><image006.jpg>_______________________________________________ > > General mailing list > > [email protected] > > http://developer.marklogic.com/mailman/listinfo/general > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > >
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
