Hi all,
On 19/set/2012, at 22:47, Lukas Kahwe Smith wrote:
Hi,
Just wanted to bring up how this all relates to custom index solutions (like
Solr/ES). Isnt there a risk that by making it possible to attach such
configuration to nodes, that it would encourage applications that make it
On Sep 20, 2012, at 2:45 PM, Tommaso Teofili teof...@adobe.com wrote:
Hi all,
On 19/set/2012, at 22:47, Lukas Kahwe Smith wrote:
Hi,
Just wanted to bring up how this all relates to custom index solutions (like
Solr/ES). Isnt there a risk that by making it possible to attach such
Hi,
It is problematic to fix the configuration if you don't know where to
look, if the configuration can be basically anywhere in the repository.
Let's say there are special Lucene indexes configured at:
/long/path/deep/in/repository
And if you want to switch to another query engine (let's
Hi,
On Thu, Sep 20, 2012 at 2:48 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
i think it would be ideal if in most cases switching the internal lucene
solution
for Solr/ES should work without having to touch anything beyond a few configs
(which can of course be stored inside the repo).
Hi,
On Thu, Sep 20, 2012 at 4:49 PM, Thomas Mueller muel...@adobe.com wrote:
Yes, but the problem is if the repository-administrator has no way of
knowing what indexes are configured.
That's easy to find out:
SELECT * FROM [oak:indexed]
;-)
BR,
Jukka Zitting
Hi,
Yes, but the problem is if the repository-administrator has no way of
knowing what indexes are configured.
That's easy to find out:
SELECT * FROM [oak:indexed]
;-)
Your are right. To do this efficiently it would require an index on
[oak:indexed], which would effectively be the same
Hi,
On Thu, Sep 20, 2012 at 7:50 PM, Thomas Mueller muel...@adobe.com wrote:
Your are right. To do this efficiently it would require an index on
[oak:indexed], which would effectively be the same as having the list of
indexes (and where they are configured) stored at a central place...
Right.
Hi,
At query time, when it knows the main path constraint used in the
query, it can walk down that path to detect which indexes are
available and useful for resolving the query.
I guess we could make it work. It would make the query engine a bit more
complex, and some of the queries would get a
Hi,
There is one more problem with storing the index config near the content.
The index config doesn't just need to be read when running a query, but
also when modifying data, in order to update the index data itself. If the
index config isn't stored at a central place, then either the index
On 18.09.2012, at 17:14, Jukka Zitting jukka.zitt...@gmail.com wrote:
First of all I think there shouldn't be just one single place in the
repository where all index configuration should go. It would be nice
if users and applications could define custom indexes on areas they
have write access
Hi,
+1
From a content modeling perspective, forcing all indexes in a central
location is very restricting and not modular.
Where the index configuration nodes are stored is normally internal to the
implementation, with the exceptions of export and import.
The index configuration is similar to
On Wed, Sep 19, 2012 at 2:26 PM, Thomas Mueller muel...@adobe.com wrote:
Jukka wrote:
When executing a query, the search engine in Oak would then detect all
indexes along the main path axis of a given query. For example, when
querying for content inside /data/foo, the search engine would use
On Sep 19, 2012, at 3:48 PM, Bertrand Delacretaz bdelacre...@apache.org wrote:
On Wed, Sep 19, 2012 at 2:26 PM, Thomas Mueller muel...@adobe.com wrote:
Jukka wrote:
When executing a query, the search engine in Oak would then detect all
indexes along the main path axis of a given query. For
On Wed, Sep 19, 2012 at 3:50 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On Sep 19, 2012, at 3:48 PM, Bertrand Delacretaz bdelacre...@apache.org
wrote:
...Currently, Jackrabbit mostly considers the repository as a monolithic
unit of content, yet typical applications have widely varying
Hi,
On Wed, Sep 19, 2012 at 9:30 PM, Ard Schrijvers
a.schrijv...@onehippo.com wrote:
I've read the entire thread, and below reply inline to the initial
proposal of Jukka as I have some doubts in that area:
Great comments, thanks for joining the discussion!
The only way I could imagine we
Hi,
Just wanted to bring up how this all relates to custom index solutions (like
Solr/ES). Isnt there a risk that by making it possible to attach such
configuration to nodes, that it would encourage applications that make it close
to impossible to switch to Solr/ES to benefit from their
On Wed, Sep 19, 2012 at 10:39 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Wed, Sep 19, 2012 at 9:30 PM, Ard Schrijvers
a.schrijv...@onehippo.com wrote:
I've read the entire thread, and below reply inline to the initial
proposal of Jukka as I have some doubts in that area:
Great
Hi,
We now have a couple of initial index implementations for Oak and some
ideas on how index configuration could/should work. In order to start
unifying those approaches and to find some common consensus, I'd like
to throw out an idea of how I think index configuration should work in
Oak.
On Sep 18, 2012, at 5:14 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
We now have a couple of initial index implementations for Oak and some
ideas on how index configuration could/should work. In order to start
unifying those approaches and to find some common consensus, I'd like
Hi,
On Tue, Sep 18, 2012 at 5:16 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
would this also allow to offer something similar to the virtual nodes based
on facettes
that HippoCMS currently offers?
Not directly, but more on that concept soon in a separate thread.
BR,
Jukka Zitting
Hi,
First of all I think there shouldn't be just one single place in the
repository where all index configuration should go.
Hm, how would the query engine detect what indexes are available? I think
keeping the index configuration at one place is the most simple solution,
and I don't currently
21 matches
Mail list logo
