similar to: Encoding input

Hi ANyone to answer specifically ? Q1 : get_last_uid -> Is this the last UID indexed (which may be not the greatest value), or the gratest value (which may not be the latest) (the code of existing plugins is unclear about this, Solr looks for the greatest for insance) Q2 : WHen Indexing an email, the data is not passed by "build_key". Why so ? What is the link with

For "rescan " and "optimize", wouldn't it be the dovecot core who indicate which are to be dismissed (expunged), or re-ask for indexing a particular (or all) uid ? WHy would the backend be aware of the transactions on the mailbox ??? There is alredy "fts_backend_xxx_update_expunge", so I beleive the management of the expunged messages is *NOT* in the backend,

Op 06/01/2019 om 01:00 schreef Joan Moreau: > Anyone willing to explain those functions ? > > Most notably " get_last_uid" From src/plugins/fts/fts-api.h: /* Get the last_uid for the mailbox. */ int fts_backend_get_last_uid(struct fts_backend *backend, struct mailbox *box, ??? ??? ??? ???? uint32_t *last_uid_r); The solr sources (

also, for fts_backend_solr_update_set_build_key -> where is the data (of the hdr_name or the body) ? On 2019-01-06 14:10, Joan Moreau wrote: > for the "last uid"-> this is not the last added, but the maximum of the UID in the indexed emails, right ? > > On 2019-01-06 11:53, Joan Moreau via dovecot wrote: > > Thank you > > I still don't get the

for fts_backend_xxx_lookup, where is specidifed in which field (to, cc, subject, body, from, all) to lookup ? On 2019-01-06 16:03, Joan Moreau wrote: > For "rescan " and "optimize", wouldn't it be the dovecot core who indicate which are to be dismissed (expunged), or re-ask for indexing a particular (or all) uid ? WHy would the backend be aware of the transactions on

for the "last uid"-> this is not the last added, but the maximum of the UID in the indexed emails, right ? On 2019-01-06 11:53, Joan Moreau via dovecot wrote: > Thank you > > I still don't get the "build_key" function. The email (body, hearders, .. and the uid) is the one (and only) to index . What "key" is that function referring to ? Or is the

Thank you I still don't get the "build_key" function. The email (body, hearders, .. and the uid) is the one (and only) to index . What "key" is that function referring to ? Or is the "key" here the actual email ? On 2019-01-06 08:43, Stephan Bosch wrote: > Op 06/01/2019 om 01:00 schreef Joan Moreau: > >> Anyone willing to explain those functions

and finally , for fts_backend_xxxx_lookup_multi, why is that backend dependent ? Would- nt the below function below be the same for any backend ? Waiting fro your feedback on all those questions Thank you JM ----------------- static int fts_backend_xapian_lookup_multi(struct fts_backend *_backend, struct mailbox *const boxes[], struct mail_search_arg *args, enum fts_lookup_flags flags,

On 7 Jan 2019, at 16.05, Joan Moreau via dovecot <dovecot at dovecot.org> wrote: > > Hi > > ANyone to answer specifically ? > > Q1 : get_last_uid -> Is this the last UID indexed (which may be not the greatest value), or the gratest value (which may not be the latest) (the code of existing plugins is unclear about this, Solr looks for the greatest for insance) All the

Duh... src/lib/restrict-process-size.h Should be in the installed include files as well, /usr/include/dovecot/restrict-process-size.h Aki > On 06/11/2020 15:56 Joan Moreau <jom at grosjo.net> wrote: > > > Hello > I can't find "src/lib/restrict.h" . Is it in dovecot source ? > > > On 2020-11-06 13:20, Aki Tuomi wrote: > > Seems I had

Inbox appears in the list of arguments, because fts_backend_xapian_lookup() is parsing the search args wrong. Not sure about the other issue. > On 21 Apr 2019, at 19.31, Joan Moreau <jom at grosjo.net> wrote: > > For this first point, the problem is that dovecot core sends TWICE the request and "Inbox" appears in the list of arguments ! (inbox shall serve to select teh

You could also add it as setting for the fts_xapian plugin parameters? Aki > On 04/11/2020 08:42 Joan Moreau <jom at grosjo.net> wrote: > > > For machines with low memory, I would like to detect how much ram remains available before starting indexing a mail, so I can commit everything on disk before the ram is exhausted (and break the process) > I tried to put a

On 3 Apr 2019, at 20.30, Joan Moreau via dovecot <dovecot at dovecot.org> wrote: > doveadm search -u jom at grosjo.net mailbox inbox text milan > output > > doveadm(jom at grosjo.net): Info: Query : ( bcc:inbox OR body:inbox OR cc:inbox OR from:inbox OR message-id:inbox OR subject:inbox OR to:inbox OR uid:inbox ) AND ( bcc:milan OR body:milan OR cc:milan OR from:milan OR

It's because you're misunderstanding how the lookup() function works. It gets ALL the search parameters, including the "mailbox inbox". This is intentional, and not a bug. Two reasons being: 1) The FTS plugin in theory could support indexing/searching any kinds of searches, not just regular word searches. So I didn't want to limit it unnecessarily. 2) Especially with

Seems I had forgotten that you can use src/lib/restrict.h, in particular, restrict_get_process_size() to figure out the limit. You can combine this with getrusage to find out current usage. Aki > On 06/11/2020 13:26 Joan Moreau <jom at grosjo.net> wrote: > > > yes, will do so. > It would be nice however to be able to access the actual dovecot config from the plugin side

Op 14-1-2019 om 13:40 schreef Aki Tuomi: > > Just to remind that now that there is a github repo for fts-xapian, > you could maybe open these issues there instead? > Although README.md currently says: "Please feel free to send your questions, together with the dovecot log file, to jom at grosjo.net <mailto:jom at grosjo.net> or to the dovecot ML dovecot at dovecot.org

THis is already what I send earlier (see : dovecot-xapian-1.0b2.tar.gz [1] ) What I would need is the files so one can download (git) it, and type some command (make ?) to compile it and place it in the right forlder (/usr/lib/dovecot/ or whatever is configured in the installed dovecot, which may differ from distribution to distribution) On 2019-01-13 19:47, Aki Tuomi wrote: > You need

Testing a compile on FreeBSD. gmake[2]: Entering directory '/usr/home/wash/Tools/Dovecot/fts-xapian/src' /bin/sh ../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I.. -I/opt/dovecot2.3/include/dovecot -I/opt/dovecot2.3/include/dovecot -g -O2 -MT fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c -o fts-backend-xapian.lo fts-backend-xapian.cpp libtool:

On 2 Apr 2019, at 6.38, Joan Moreau via dovecot <dovecot at dovecot.org> wrote: > > Further on this topic: > > > > When choosing any headers in the search box, dovecot core calls the plugin TWICE (and returns the results quickly, but not immediatly after getting the IDs from the plugins) > > When choosing the BODY search, dovecot core calls the plugin ONCE (and

ok found it, However, it returns me some random number. Maybe I am missing something On 2020-11-06 13:57, Aki Tuomi wrote: > Duh... src/lib/restrict-process-size.h > > Should be in the installed include files as well, > > /usr/include/dovecot/restrict-process-size.h > > Aki > > On 06/11/2020 15:56 Joan Moreau <jom at grosjo.net> wrote: > > Hello >