I've finally fixed it. Sorry it took so long. See my reply below.
On 07/16/2017 06:25 PM, Dan Haywood wrote:
Fixed. No, no good reason. I was playing around because at some point I
noticed multiple clients were created in our application and I wanted to
find out how this happened.
Fixed. No test-directory existed and I didn't notice the files were
created in the java-directory.
Some setting might be application specific because different
applications might require diffent search/index behaviour. At some time
I was testing different indexing strategies to improve our search
engine. I didn't know what to do with this so I just left it there. This
could be solved by adding a hook like you mention below.
Fixed. I should take a better look at exception handling. It's easy to
make a mess of that.
Fixed. Didn't use any JAXB view models yet.
Fixed. Will the optionality-property disappear in future versions of
Apache Isis. Is there any difference?
Like mentioned above 'addMappings' could be a hook to improve/change
We call 'initialiseSearchEngine' every night to recreate the index. Our
database is used by multiple applications (and sometimes even updated by
hand :-/ ) and these applications also update the same ElasticSearch
index. We recreate the index just to be sure it's up to date at least at
the beginning of the day. I can imagine this is not really needed for
'addToBulkRequest' is used by above initialisation.
The search search now only returns the first (I believe) 25 results from
ElasticSearch. If the current user isn't allowed to see (some of) these
results then no (or less) results will be displayed while the index
contains a lot of items matching the search criteria the user ís allowed
to see. So we have to check the tenancy while searching, so
ElasticSearch only returns items the current user is allowed to see.
This might give problems when using multiple applications talking to the
same index. At least there must be a common way to mark the indexed
items with an id both applications understand.
Probably better than let the index transform itself (this is only
something that happens in movies)
Right now the index-field of the Indexer-class is used by subclasses. It
could be changed to an interface but then the creation of the JSON must
be moved outside the Indexer-classes and that's the only thing they do now.
I was wondering this too but I'm not yet confident enough with the meta
model to refactor this using annotations.
The way I implemented it now, we have to add some new classes and
register these to the IndexerFactory and add methods to the domain
objects we want to be index