RFC: Similiarity index with trigger

Showing 1-41 of 41 messages
RFC: Similiarity index with trigger Christoph Hochreiner 3/18/12 4:03 AM
Hi,

the first prototype of the similarity infrastructure is finished and i'd like some comments/reviews.

The EDB accesses the similarity service with triggers (former hooks, but renamed due to the fact that they actually do not change the EDB-Objects). They can be found in [1]. According to Felix there should not be that many problems with implementing them into the current EDB infrastructure. The basic assumption is that the triggers present in the OSGI registry are not existing (--> no overhead). If there are triggers, they are used.
The triggers [2] themselves are only adapter to the similarity index, that call the correct implementation based on service properties. 
The current similarity index implementation contains an lucene implementation, but it could be replaced with other (almost certainly faster services) in the future. Currently there are 4 sample implementations for different index implementations. There was an idea to put the configuration into config files an load them on the fly (similar to the ConnectorDeployerService), but imho there are some downsides/unsolved problems.
- the index creation could use more advanced java code --> problematic to store them in config files
- if i use hotdeploy for the index, there has to be some configuration in the trigger (no real hotdeploy possible; you could use some wiring techniques, but i don't know if that would be too much overhead)

The pros would be:
- hotdeploy
- no configuration code in the similarity service

So overall: WDYT?
There is a features.xml[4].

best regards 
Christoph


Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/18/12 7:54 AM
I had now a quick look at the complete code of the similarity things and it looks quit good. Just two micro things to add:
*) I think that Index is maybe a little bit too generic name for that. Maybe ModelIndex or something like that. Index could be anything.
*) javadoc would be nice here and there.

Kind regards
Felix
Re: RFC: Similiarity index with trigger Christoph Hochreiner 3/18/12 11:11 AM
i've updated some jdoc, should be a little bit clearer
regarding the name, i agree that the name index is to generic/already taken(e.g. Lucene Index);
ModelIndex is IMHO not the best name, because the current index does not necessarily represent the whole model.

~Christoph
Re: RFC: Similiarity index with trigger Andreas Pieber 3/18/12 11:46 AM
Hey

On Sun, Mar 18, 2012 at 12:03, Christoph Hochreiner
<ch.hoc...@gmail.com> wrote:
> the first prototype of the similarity infrastructure is finished and i'd
> like some comments/reviews.
>
> The EDB accesses the similarity service with triggers (former hooks, but
> renamed due to the fact that they actually do not change the EDB-Objects).
> They can be found in [1].

OK, I can life with the argumentation that they change nothing
(although  I would still prefer the name hook). Nevertheless in that
case listener might be better than triggers?

> According to Felix there should not be that many
> problems with implementing them into the current EDB infrastructure. The
> basic assumption is that the triggers present in the OSGI registry are not
> existing (--> no overhead). If there are triggers, they are used.
> The triggers [2] themselves are only adapter to the similarity index, that
> call the correct implementation based on service properties.

Do I get it right that there is no implementation right now?

> The current similarity index implementation contains an lucene
> implementation, but it could be replaced with other (almost certainly faster
> services) in the future. Currently there are 4 sample implementations for
> different index implementations. There was an idea to put the configuration
> into config files an load them on the fly (similar to the
> ConnectorDeployerService), but imho there are some downsides/unsolved
> problems.
> - the index creation could use more advanced java code --> problematic to
> store them in config files
> - if i use hotdeploy for the index, there has to be some configuration in
> the trigger (no real hotdeploy possible; you could use some wiring
> techniques, but i don't know if that would be too much overhead)
>
> The pros would be:
> - hotdeploy
> - no configuration code in the similarity service
>
> So overall: WDYT?
> There is a features.xml[4].

Basically you code looks OK, but I don't get it where exactly you
would like to have our feedback. What do you plan to do with those
hooks? Do we like to provide them as part of the engsb? *confused*

kind regards,
Andreas

>
> best regards
> Christoph
>
> [1] https://github.com/chhochreiner/openengsb-framework/tree/edbtrigger
> [2] https://github.com/chhochreiner/EDBHook
> [3] https://github.com/chhochreiner/similarityIndexPrototype
> [4]
> https://github.com/chhochreiner/similarityIndexPrototype/blob/master/src/main/filtered-ressources/features.xml
>

Re: RFC: Similiarity index with trigger Christoph Hochreiner 3/18/12 12:42 PM


On Sunday, March 18, 2012 7:46:31 PM UTC+1, Andreas Pieber wrote:
Hey

On Sun, Mar 18, 2012 at 12:03, Christoph Hochreiner
<ch.hoc...@gmail.com> wrote:
> the first prototype of the similarity infrastructure is finished and i'd
> like some comments/reviews.
>
> The EDB accesses the similarity service with triggers (former hooks, but
> renamed due to the fact that they actually do not change the EDB-Objects).
> They can be found in [1].

OK, I can life with the argumentation that they change nothing
(although  I would still prefer the name hook). Nevertheless in that
case listener might be better than triggers? 

So currently there are three different names:
# hook
+ the concept behind are basically hooks
- possible collision of names/concepts with weaver hooks

# trigger
+ based in the database name space
- with this hooks, the elements do not get altered like in pl/sql; there are only external effects

# listener
+ describes the functionality of this hooks

WDYT?
 

> According to Felix there should not be that many
> problems with implementing them into the current EDB infrastructure. The
> basic assumption is that the triggers present in the OSGI registry are not
> existing (--> no overhead). If there are triggers, they are used.
> The triggers [2] themselves are only adapter to the similarity index, that
> call the correct implementation based on service properties.

Do I get it right that there is no implementation right now?

yes, there is no actual implementation/"usage" in the EDB right now, FMa plans to look at it after his exam. (this Fr)
Should only require some minor changes.
 

> The current similarity index implementation contains an lucene
> implementation, but it could be replaced with other (almost certainly faster
> services) in the future. Currently there are 4 sample implementations for
> different index implementations. There was an idea to put the configuration
> into config files an load them on the fly (similar to the
> ConnectorDeployerService), but imho there are some downsides/unsolved
> problems.
> - the index creation could use more advanced java code --> problematic to
> store them in config files
> - if i use hotdeploy for the index, there has to be some configuration in
> the trigger (no real hotdeploy possible; you could use some wiring
> techniques, but i don't know if that would be too much overhead)
>
> The pros would be:
> - hotdeploy
> - no configuration code in the similarity service
>
> So overall: WDYT?
> There is a features.xml[4].

The plan was to maintain the similarity index [3] as part of the engsb.
The problem here is, how to handle the concrete implementations:
- should there be some sample implementations (like StandardIndex or ComplexIndex), to show the functionality or should this be only documented in the documentation.
- how should we handle the trigger --> again should there be some dummy implementations or only documentation

Besides the current implementation i've another idea:
create concrete instances of the index in the Trigger (define the two methods addDocument(EDBObject c) and buildQueryString(EDBObject sample) there) and maintain only the abstract similarity index

pro:
- configuration gets out of the similarity index package and into the concrete implementation of the hooks

con:
- with the current setup the concrete index implementation has to be defined twice (unless you merge the EDBHook Interfaces)
- when you are using different index definitions, all of them have to be defined in this hook --> the hooks get more configuration code/no generalization (code reuse)

if this is not clear I'll provide a quick prototype of this "architecture"

~Christoph
Re: RFC: Similiarity index with trigger Christoph Hochreiner 3/18/12 1:10 PM
Short Update:

the implementation would look somehow like this:

the main advantage would be that we only have to document the functionality but need not have any configuration in the implementation.
The triggers would be completely user/customer specific.

~Christoph
Re: RFC: Similiarity index with trigger Andreas Pieber 3/18/12 7:59 PM
Hey,

On Sun, Mar 18, 2012 at 20:42, Christoph Hochreiner
<ch.hoc...@gmail.com> wrote:
> On Sunday, March 18, 2012 7:46:31 PM UTC+1, Andreas Pieber wrote:

</SKIP>

> So currently there are three different names:
> # hook
> + the concept behind are basically hooks
> - possible collision of names/concepts with weaver hooks
>
> # trigger
> + based in the database name space
> - with this hooks, the elements do not get altered like in pl/sql; there are
> only external effects
>
> # listener
> + describes the functionality of this hooks
>
> WDYT?

I still think Hook is the best name (since the EDB is kind of an SCM
and hook is the name typically used for the scripts interacting with
the process there. Nevertheless my second favor would be listener,
since I've other situations with a trigger... @ChristophGr what do you
think about this? IIRC the Trigger name was invented by you.


OK, after giving the code a second look and reading your detailed
descriptions I'm getting an idea of what you're planing the to (at
least I think so :-)). The question is: is there a way to provide an
option to configure the similarity index in a way that you can adapt
it without changing the code.

Yes: Great, include it into the OpenEngSB per se
No: Include it only in documentation and provide only a library (in a
seperate labs-XXX proejct) and document how this library could be used
in hooks.

I think you answered those questions partly in previous posts;
nevertheless can you summarize them here again to make the decision
process clear for all?

Thank you very much for your effort and kind regards,
Andreas

Re: RFC: Similiarity index with trigger Christoph Gritschenberger 3/19/12 1:45 AM
Hi,

On 03/19/2012 03:59 AM, Andreas Pieber wrote:
>
> I still think Hook is the best name (since the EDB is kind of an SCM
> and hook is the name typically used for the scripts interacting with
> the process there. Nevertheless my second favor would be listener,
> since I've other situations with a trigger... @ChristophGr what do you
> think about this? IIRC the Trigger name was invented by you.

Listeners is fine with me.
SCM-hooks can also change the content of e.g. the commit-message. Also
they can be executed _before_ an action.

>
>
> OK, after giving the code a second look and reading your detailed
> descriptions I'm getting an idea of what you're planing the to (at
> least I think so :-)). The question is: is there a way to provide an
> option to configure the similarity index in a way that you can adapt
> it without changing the code.
>
> Yes: Great, include it into the OpenEngSB per se
> No: Include it only in documentation and provide only a library (in a
> seperate labs-XXX proejct) and document how this library could be used
> in hooks.

Problem is, that the code relies on the EDB notifying the listeners
which requires the interfaces to be added to the API and some minor
changes to the EDB.

kind regards,
christoph


---------------------------------------------------------------

Re: RFC: Similiarity index with trigger Andreas Pieber 3/19/12 2:22 AM
Hey

On Mon, Mar 19, 2012 at 09:45, Christoph Gritschenberger
<christoph.gr...@gmail.com> wrote:
> Hi,
>
> On 03/19/2012 03:59 AM, Andreas Pieber wrote:
>>
>> I still think Hook is the best name (since the EDB is kind of an SCM
>> and hook is the name typically used for the scripts interacting with
>> the process there. Nevertheless my second favor would be listener,
>> since I've other situations with a trigger... @ChristophGr what do you
>> think about this? IIRC the Trigger name was invented by you.
>
> Listeners is fine with me.
> SCM-hooks can also change the content of e.g. the commit-message. Also
> they can be executed _before_ an action.

Well we can also define before and after hooks; and some of them might
also be able to change values. TBH I don't see a problem with that, do
you?

>> OK, after giving the code a second look and reading your detailed
>> descriptions I'm getting an idea of what you're planing the to (at
>> least I think so :-)). The question is: is there a way to provide an
>> option to configure the similarity index in a way that you can adapt
>> it without changing the code.
>>
>> Yes: Great, include it into the OpenEngSB per se
>> No: Include it only in documentation and provide only a library (in a
>> seperate labs-XXX proejct) and document how this library could be used
>> in hooks.
>
> Problem is, that the code relies on the EDB notifying the listeners
> which requires the interfaces to be added to the API and some minor
> changes to the EDB.

Sorry for not being clear on that point. Of course the API needs to be
included; I'm rather talking about the other components (similarity
checker, ...)

Kind regards,
Andreas

Re: RFC: Similiarity index with trigger Christoph Gritschenberger 3/19/12 2:41 AM
Sounds OK for me.
When we allow modification, I'm OK with calling them hooks again.

kind regards,
christoph

Re: RFC: Similiarity index with trigger Andreas Pieber 3/19/12 3:26 AM

Maybe not all hooks, but definitely some

Kind regards

Send from my mobile. Please excuse the brevity and/or possible auto correction errors.

Re: RFC: Similiarity index with trigger Christoph Hochreiner 3/19/12 5:26 AM
Hey,
so some news on the codebase:
- there is a new EDBHook interface that covers the 3 old interfaces [1]
  the reason for this was to reduce the configuration overhead for the new EDBHook Implementations
  --> should go into the openengsb codebase; implementation for EDB comes from felix m. in 2-3 weeks
- the EDBHook represents an industrial usecase implementation for the Hook [2]
  --> should be documented how to write this and/or be part of a labs project
- similarity service [3]
  the Abstract index is not really abstract anymore; there is a default implementation (index all fields and search all fields with levenstein similarity 80%
  this abstract service should be extended as you can see in the EDBHook --> no prject specific configuration is here
  --> similarity service should become an openengsb project like the connectors (git, jira, ...)

IMHO there are some things to do/discuss:
- renaming index to a less taken name:
  suggestions: 
  # ModelIndex
  # SimilarityIndex
- adopt similarity project code according to quality guidelines of openengsb

best regards
Christoph






Re: RFC: Similiarity index with trigger Andreas Pieber 3/19/12 8:42 AM
Hey,

On Mon, Mar 19, 2012 at 13:26, Christoph Hochreiner
<ch.hoc...@gmail.com> wrote:
> so some news on the codebase:
> - there is a new EDBHook interface that covers the 3 old interfaces [1]
>   the reason for this was to reduce the configuration overhead for the new
> EDBHook Implementations
>   --> should go into the openengsb codebase; implementation for EDB comes
> from felix m. in 2-3 weeks

+1, but we're not settled on the methods right now tbh. (1) I really
preferred to keep them separated. You should be able to register a
single concern and should not be forced to register to all at once and
simple ignored the call. In addition I don't get who calls the recover
method one. I'm also not sure who and when calls the collision method.

> - the EDBHook represents an industrial usecase implementation for the Hook
> [2]
>   --> should be documented how to write this and/or be part of a labs
> project
> - similarity service [3]

Great, we can document them independently in the labs project. IMHO we
should keep the documentation in the the github wiki there (as for all
other lab projects) and also keep the issues there for the lab
project; issues affecting the openengsb should still be created at
issues.openengsb.org

>   the Abstract index is not really abstract anymore; there is a default
> implementation (index all fields and search all fields with levenstein
> similarity 80%
>   this abstract service should be extended as you can see in the EDBHook -->
> no prject specific configuration is here

Not quite sure this should happen; can you explain please?

>   --> similarity service should become an openengsb project like the
> connectors (git, jira, ...)

In that case we need to create a connector/domain. Not sure how this
makes sense. IMHO we should not include such extensions too far into
the core but rather focus on the connector/domain/workflow things and
keep such extensions in labs for ppl interested in those more exotic
use cases.

> IMHO there are some things to do/discuss:
> - renaming index to a less taken name:
>   suggestions:
>   # ModelIndex
>   # SimilarityIndex

I like both and will follow others here. Felix? ChristophGr? Any suggestions?

> - adopt similarity project code according to quality guidelines of openengsb

+1; best to do this at pull requests. IMHO we should start with the
API. Once this is fixed (and cleaned up during the pull-request phase)
I'll create the additional lab project and we'll do the same there in
the pull-request.

WDYT?

Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/19/12 12:17 PM
Hey,

Am 2012-03-19 16:42, schrieb Andreas Pieber:
> Hey,
>
> On Mon, Mar 19, 2012 at 13:26, Christoph Hochreiner
> <ch.hoc...@gmail.com>  wrote:
>> so some news on the codebase:
>> - there is a new EDBHook interface that covers the 3 old interfaces [1]
>>    the reason for this was to reduce the configuration overhead for the new
>> EDBHook Implementations
>>    -->  should go into the openengsb codebase; implementation for EDB comes
>> from felix m. in 2-3 weeks
> +1, but we're not settled on the methods right now tbh. (1) I really
> preferred to keep them separated. You should be able to register a
> single concern and should not be forced to register to all at once and
> simple ignored the call. In addition I don't get who calls the recover
> method one. I'm also not sure who and when calls the collision method.
Maybe the separation is not necessary. One thing I could imagine is that
we create an abstract class EDBHook, which implements this interface and
simply do nothing in each method. If the user wants to add an EDBHook,
he just create a bundle and extend the methods he want to include in
this hook. The EDB then would then call at specific code positions all
EDBHooks which are in the running OSGi environment.

About the collision method: what collision method? I thought we just
call an EDBHook method which gives us, if at least one EDBHook is
running, similar objects back in the event that some models can't be
updated. When this Hook method shall be called is the work of the EDB.

>> - the EDBHook represents an industrial usecase implementation for the Hook
>> [2]
>>    -->  should be documented how to write this and/or be part of a labs
>> project
>> - similarity service [3]
> Great, we can document them independently in the labs project. IMHO we
> should keep the documentation in the the github wiki there (as for all
> other lab projects) and also keep the issues there for the lab
> project; issues affecting the openengsb should still be created at
> issues.openengsb.org
>
>>    the Abstract index is not really abstract anymore; there is a default
>> implementation (index all fields and search all fields with levenstein
>> similarity 80%
>>    this abstract service should be extended as you can see in the EDBHook -->
>> no prject specific configuration is here
> Not quite sure this should happen; can you explain please?
>
>>    -->  similarity service should become an openengsb project like the
>> connectors (git, jira, ...)
> In that case we need to create a connector/domain. Not sure how this
> makes sense. IMHO we should not include such extensions too far into
> the core but rather focus on the connector/domain/workflow things and
> keep such extensions in labs for ppl interested in those more exotic
> use cases.
I wouldn't do that on the base of connector/domain, but rather handle an
EDBHook implementation simply as a bundle which exports a service for
that (like already written above). Then the user can simply add such a
service himself and the only thing to do is to provide such a service.
In that way it wouldn't go too much into the core, just the api things.

>> IMHO there are some things to do/discuss:
>> - renaming index to a less taken name:
>>    suggestions:
>>    # ModelIndex
>>    # SimilarityIndex
> I like both and will follow others here. Felix? ChristophGr? Any suggestions?
I think ModelIndex is better, since the EDB works with models and the
service does a search for similar models. But I don't know in which way
this feature could be differently used in future.

Kind regards,
Felix

Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/19/12 12:23 PM
Ok, have now seen what introduces confusion. Maybe EDBCollisionHook is not a good name, since AFAIK the similarity checker isn't needed for collisions, but for updating errors. I think collision detection is something that shouldn't be done with hooks. At least not now and not at this layer. The EDB's collision detection works really low level (compare key value paris for change if the version number is a different one as it should be). Complicated collision detection should be part of the EKB and have nothing to do with the hooks for the EDB. That's future stuff.

Kind regards
Felix
Re: RFC: Similiarity index with trigger Christoph Gritschenberger 3/20/12 12:01 AM
Hi,


On 03/19/2012 08:17 PM, Felix Mayerhuber wrote:
> Hey,


>
> Maybe the separation is not necessary. One thing I could imagine is that
> we create an abstract class EDBHook, which implements this interface and
> simply do nothing in each method. If the user wants to add an EDBHook,
> he just create a bundle and extend the methods he want to include in
> this hook. The EDB then would then call at specific code positions all
> EDBHooks which are in the running OSGi environment.

Well, I'm not so sure about this. This should only be done if there are
a lot of methods to implement. Drools for example handles
AgendaListeners that way. The "DefaultAgendaListener" has about 20
Methods (beforeRuleActivated, afterNodeFinished, ...). And there is a
great chance the user may want to implement several of these methods.
Providing an interface for each method would be quite tedious.
In our case there are only 3(?) methods and mostly you only want to
implement one. In that case I favor an interface for each method.

kind regards,
christoph

Re: RFC: Similiarity index with trigger Andreas Pieber 3/20/12 12:12 AM
I'm with Christoph on this point; IMHO we should handle them
separately; at least for now.

Kind regards,
Andreas

On Tue, Mar 20, 2012 at 08:01, Christoph Gritschenberger

Re: RFC: Similiarity index with trigger Christoph Hochreiner 3/20/12 1:39 AM
basically i'm with you, concerning the separation of interfaces, although at the moment the will be used in one "step" (pre/post commit)

this trigger the question if we should rename them to pre/post commit hooks or leave the names (as CGr raised on github)
pro for renaming:
- pre/post describe the current behavior
con:
if there are additional hooks, it could be better to name the hooks according to their actions and not their phases

~Christoph
Re: RFC: Similiarity index with trigger Andreas Pieber 3/20/12 1:53 AM
Well, since the EDB is quite similar to an SCM I think using similar
names for similar actions would help devs and make things more similar
to them. Therefore pre-commit, post-commit, ... feels pretty good.

Kind regards,
Andreas

Re: RFC: Similiarity index with trigger Christoph Hochreiner 3/20/12 2:22 AM
OK, then i'll rename them:

EDBCollisionHook --> EDBPreCommitHook
EDBUpdateHook --> EDBPostCommitHook

i'm not sure how to handle the EDBErrorHook
this hook is intended to trigger a rebuild of the index (bad results, major rollback of commits, ...)

here it's the question if it should stay EDBErrorHook or should become

- EDBRecorveryHook
- EDBRestoreHook
- EDBRebuildIndexHook

~Christoph
Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/20/12 2:29 AM
Am 2012-03-20 10:22, schrieb Christoph Hochreiner:
> OK, then i'll rename them:
>
> EDBCollisionHook -->  EDBPreCommitHook
> EDBUpdateHook -->  EDBPostCommitHook
>
> i'm not sure how to handle the EDBErrorHook
> this hook is intended to trigger a rebuild of the index (bad results, major
> rollback of commits, ...)
>
> here it's the question if it should stay EDBErrorHook or should become
>
> - EDBRecorveryHook
> - EDBRestoreHook
> - EDBRebuildIndexHook
>
> ~Christoph
Hi,

Now I'm confused. What should the PreCommitHook now do? At least now we
havn't a usecase where we need that? And the similarity check isn't
something that needs to be done in the precommit. Only if there is a
problem when you want to update a model. And if that happens, I need the
list of OID's which are similar to that models which have an error.

We need good names since they are crucial for the understandability of
that mechanism.

Kind regards
Felix

Re: RFC: Similiarity index with trigger Andreas Pieber 3/20/12 2:32 AM
what about an error hook?

Kind regards,
Andreas

Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/20/12 2:37 AM
We could introduce an ErrorHook "needSimilarModels", but I don't know
how to name that properly. Also something like that is very specific.
Maybe we should take a step back think about what our usecases are, what
we really need and what could be interessting in the future.

Kind regards,
Felix

Re: RFC: Similiarity index with trigger Andreas Pieber 3/20/12 2:56 AM
+1 on that; It feels right now as if every approach is VERY specific
to the solution ChristophH requires. I don't think we want it that way
in the core. The first question: what exactly do we need to interrupt?
Basically I want to have a list of what exactly we want to do. Maybe
we need to move some logic/functionality from the EDB to the hooks to
make sure that we have the right lvl of abstraction.

Kind regards,
Andreas

Re: RFC: Similiarity index with trigger Christoph Gritschenberger 3/20/12 3:22 AM
From what I get what we need is this:
-------
invokeAllOsgiServices(PreCommitHook.class)
try {
        edb.commit()
catch(Exception e){
        invokeAllOsgiServices(ErrorHook.class)
        throw e;
}
invokeAllOsgiServices(PostCommitHook.class)
-------

I would name the hook-interfaces after where they are executed.
The implementations are then named after what they do.

So for every stage there may exist 0..* hook-services registered. They
are executed in order following the standard-osgi ranking-rules (as in
spec).

The ExceptionHandling can be similar to WeavingHooks as specified in
OSGi Core 4.3.

kind regards,
christoph

Re: RFC: Similiarity index with trigger Christoph Gritschenberger 3/20/12 3:23 AM
From what I get what we need is this:
-------
invokeAllOsgiServices(PreCommitHook.class)
try {
        edb.commit()
catch(Exception e){
        invokeAllOsgiServices(ErrorHook.class)
        throw e;
}
invokeAllOsgiServices(PostCommitHook.class)
-------

I would name the hook-interfaces after where they are executed.
The implementations are then named after what they do.

So for every stage there may exist 0..* hook-services registered. They
are executed in order following the standard-osgi ranking-rules (as in
spec).

The ExceptionHandling can be similar to WeavingHooks as specified in
OSGi Core 4.3.

kind regards,
christoph

On 03/20/2012 10:56 AM, Andreas Pieber wrote:
> +1 on that; It feels right now as if every approach is VERY specific
> to the solution ChristophH requires. I don't think we want it that way
> in the core. The first question: what exactly do we need to interrupt?
> Basically I want to have a list of what exactly we want to do. Maybe
> we need to move some logic/functionality from the EDB to the hooks to
> make sure that we have the right lvl of abstraction.
>
> Kind regards,
> Andreas
>
> On Tue, Mar 20, 2012 at 10:37, Felix Mayerhuber
> <felix.ma...@gmail.com> wrote:
>> We could introduce an ErrorHook "needSimilarModels", but I don't know how to
>> name that properly. Also something like that is very specific. Maybe we
>> should take a step back think about what our usecases are, what we really
>> need and what could be interessting in the future.
>>
>> Kind regards,
>> Felix
>>
>> Am 2012-03-20 10:32, schrieb Andreas Pieber:
>>
>>> what about an error hook?
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> On Tue, Mar 20, 2012 at 10:29, Felix Mayerhuber
>>> <felix.ma...@gmail.com>  wrote:
>>>>
>>>> Am 2012-03-20 10:22, schrieb Christoph Hochreiner:
>>>>
>>>>> OK, then i'll rename them:
>>>>>
>>>>> EDBCollisionHook -->    EDBPreCommitHook
>>>>> EDBUpdateHook -->    EDBPostCommitHook
>>>>>
>>>>> i'm not sure how to handle the EDBErrorHook
>>>>> this hook is intended to trigger a rebuild of the index (bad results,
>>>>> major
>>>>> rollback of commits, ...)
>>>>>
>>>>> here it's the question if it should stay EDBErrorHook or should become
>>>>>
>>>>> - EDBRecorveryHook
>>>>> - EDBRestoreHook
>>>>> - EDBRebuildIndexHook
>>>>>
>>>>> ~Christoph
>>>>
>>>> Hi,
>>>>
>>>> Now I'm confused. What should the PreCommitHook now do? At least now we
>>>> havn't a usecase where we need that? And the similarity check isn't
>>>> something that needs to be done in the precommit. Only if there is a
>>>> problem
>>>> when you want to update a model. And if that happens, I need the list of
>>>> OID's which are similar to that models which have an error.
>>>>
>>>> We need good names since they are crucial for the understandability of
>>>> that
>>>> mechanism.
>>>>
>>>> Kind regards
>>>> Felix
>>>>
>>>>
>>>>>
>>>>> On Tuesday, March 20, 2012 9:53:58 AM UTC+1, Andreas Pieber wrote:
>>>>>>
>>>>>> Well, since the EDB is quite similar to an SCM I think using similar
>>>>>> names for similar actions would help devs and make things more similar
>>>>>> to them. Therefore pre-commit, post-commit, ... feels pretty good.
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>> On Tue, Mar 20, 2012 at 09:39, Christoph Hochreiner
>>>>>> <ch.hoc...@gmail.com>    wrote:
>>>>>>>
>>>>>>> basically i'm with you, concerning the separation of interfaces,
>>>>>>
>>>>>> although at
>>>>>>>
>>>>>>> the moment the will be used in one "step" (pre/post commit)
>>>>>>>
>>>>>>> this trigger the question if we should rename them to pre/post commit
>>>>>>
>>>>>> hooks
>>>>>>>
>>>>>>> or leave the names (as CGr raised on github)
>>>>>>> pro for renaming:
>>>>>>> - pre/post describe the current behavior
>>>>>>> con:
>>>>>>> if there are additional hooks, it could be better to name the hooks
>>>>>>> according to their actions and not their phases
>>>>>>>
>>>>>>> ~Christoph
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, March 20, 2012 8:12:57 AM UTC+1, Andreas Pieber wrote:
>>>>>>>>
>>>>>>>> I'm with Christoph on this point; IMHO we should handle them
>>>>>>>> separately; at least for now.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>> On Tue, Mar 20, 2012 at 08:01, Christoph Gritschenberger
>>>>>>>> <christoph.gr...@gmail.com>    wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03/19/2012 08:17 PM, Felix Mayerhuber wrote:
>>>>>>>>>>
>>>>>>>>>> Hey,
>>>>>>>>>>
>>>>>>>>>> Maybe the separation is not necessary. One thing I could imagine is
>>>>>>>>>> that
>>>>>>>>>> we create an abstract class EDBHook, which implements this
>>>>>>>>>> interface
>>>>>>>>>> and
>>>>>>>>>> simply do nothing in each method. If the user wants to add an
>>>>>>
>>>>>> EDBHook,
>>>>>>>>>>
>>>>>>>>>> he just create a bundle and extend the methods he want to include
>>>>>>>>>> in
>>>>>>>>>> this hook. The EDB then would then call at specific code positions
>>>>>>
>>>>>> all
>>>>>>>>>>
>>>>>>>>>> EDBHooks which are in the running OSGi environment.
>>>>>>>>>
>>>>>>>>> Well, I'm not so sure about this. This should only be done if there
>>>>>>
>>>>>> are
>>>>>>>>>
>>>>>>>>> a lot of methods to implement. Drools for example handles
>>>>>>>>> AgendaListeners that way. The "DefaultAgendaListener" has about 20
>>>>>>>>> Methods (beforeRuleActivated, afterNodeFinished, ...). And there is
>>>>>>>>> a
>>>>>>>>> great chance the user may want to implement several of these
>>>>>>>>> methods.
>>>>>>>>> Providing an interface for each method would be quite tedious.
>>>>>>>>> In our case there are only 3(?) methods and mostly you only want to
>>>>>>>>> implement one. In that case I favor an interface for each method.
>>>>>>>>>
>>>>>>>>> kind regards,
>>>>>>>>> christoph
>>>>>>>>>
>>>>>>>>>> About the collision method: what collision method? I thought we
>>>>>>>>>> just
>>>>>>>>>> call an EDBHook method which gives us, if at least one EDBHook is
>>>>>>>>>> running, similar objects back in the event that some models can't
>>>>>>>>>> be
>>>>>>>>>> updated. When this Hook method shall be called is the work of the
>>>>>>
>>>>>> EDB.
>>>>>>>>>>>>
>>>>>>>>>>>> - the EDBHook represents an industrial usecase implementation for
>>>>>>
>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>> Hook
>>>>>>>>>>>> [2]
>>>>>>>>>>>>    -->     should be documented how to write this and/or be part
>>>>>>>>>>>> of a
>>>>>>>>>>>> labs
>>>>>>>>>>>> project
>>>>>>>>>>>> - similarity service [3]
>>>>>>>>>>>
>>>>>>>>>>> Great, we can document them independently in the labs project.
>>>>>>>>>>> IMHO
>>>>>>
>>>>>> we
>>>>>>>>>>>
>>>>>>>>>>> should keep the documentation in the the github wiki there (as for
>>>>>>
>>>>>> all
>>>>>>>>>>>
>>>>>>>>>>> other lab projects) and also keep the issues there for the lab
>>>>>>>>>>> project; issues affecting the openengsb should still be created at
>>>>>>>>>>> issues.openengsb.org
>>>>>>>>>>>
>>>>>>>>>>>>    the Abstract index is not really abstract anymore; there is a
>>>>>>>>>>>> default
>>>>>>>>>>>> implementation (index all fields and search all fields with
>>>>>>>>>>>> levenstein
>>>>>>>>>>>> similarity 80%
>>>>>>>>>>>>    this abstract service should be extended as you can see in the
>>>>>>>>>>>> EDBHook -->
>>>>>>>>>>>> no prject specific configuration is here
>>>>>>>>>>>
>>>>>>>>>>> Not quite sure this should happen; can you explain please?
>>>>>>>>>>>
>>>>>>>>>>>>    -->     similarity service should become an openengsb project
>>>>>>>>>>>> like
>>>>>>>>>>>> the
>>>>>>>>>>>> connectors (git, jira, ...)
>>>>>>>>>>>
>>>>>>>>>>> In that case we need to create a connector/domain. Not sure how
>>>>>>>>>>> this
>>>>>>>>>>> makes sense. IMHO we should not include such extensions too far
>>>>>>>>>>> into
>>>>>>>>>>> the core but rather focus on the connector/domain/workflow things
>>>>>>
>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>> keep such extensions in labs for ppl interested in those more
>>>>>>>>>>> exotic
>>>>>>>>>>> use cases.
>>>>>>>>>>
>>>>>>>>>> I wouldn't do that on the base of connector/domain, but rather
>>>>>>>>>> handle
>>>>>>>>>> an
>>>>>>>>>> EDBHook implementation simply as a bundle which exports a service
>>>>>>>>>> for
>>>>>>>>>> that (like already written above). Then the user can simply add
>>>>>>>>>> such
>>>>>>
>>>>>> a
>>>>>>>>>>
>>>>>>>>>> service himself and the only thing to do is to provide such a
>>>>>>
>>>>>> service.
>>>>>>>>>>
>>>>>>>>>> In that way it wouldn't go too much into the core, just the api
>>>>>>
>>>>>> things.
>>>>>>>>>>>>
>>>>>>>>>>>> IMHO there are some things to do/discuss:
>>>>>>>>>>>> - renaming index to a less taken name:
>>>>>>>>>>>>    suggestions:
>>>>>>>>>>>>    # ModelIndex
>>>>>>>>>>>>    # SimilarityIndex
>>>>>>>>>>>
>>>>>>>>>>> I like both and will follow others here. Felix? ChristophGr? Any
>>>>>>>>>>> suggestions?
>>>>>>>>>>
>>>>>>>>>> I think ModelIndex is better, since the EDB works with models and
>>>>>>>>>> the
>>>>>>>>>> service does a search for similar models. But I don't know in which
>>>>>>
>>>>>> way
>>>>>>>>>>
>>>>>>>>>> this feature could be differently used in future.
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Felix
>>>>>>>>>>>>
>>>>>>>>>>>> - adopt similarity project code according to quality guidelines
>>>>>>>>>>>> of
>>>>>>>>>>>> openengsb
>>>>>>>>>>>
>>>>>>>>>>> +1; best to do this at pull requests. IMHO we should start with
>>>>>>>>>>> the
>>>>>>>>>>> API. Once this is fixed (and cleaned up during the pull-request
>>>>>>
>>>>>> phase)
>>>>>>>>>>>
>>>>>>>>>>> I'll create the additional lab project and we'll do the same there
>>>>>>
>>>>>> in
>>>>>>>>>>>
>>>>>>>>>>> the pull-request.
>>>>>>>>>>>
>>>>>>>>>>> WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Kind regards,
>>>>>>>>>>> Andreas
>>>>>>>>>>>
>>>>>>>>>>>> best regards
>>>>>>>>>>>> Christoph
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [1]
>>>>>>>>>>>>
>>>>>> https://github.com/chhochreiner/openengsb-framework/tree/edbtrigger
>>>>>>>>>>>>
>>>>>>>>>>>> [2] https://github.com/chhochreiner/EDBHook
>>>>>>>>>>>> [3] https://github.com/chhochreiner/similarityIndexPrototype
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Monday, March 19, 2012 10:22:22 AM UTC+1, Andreas Pieber
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hey
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Mar 19, 2012 at 09:45, Christoph Gritschenberger
>>>>>>>>>>>>> <christoph.gr...@gmail.com>     wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/19/2012 03:59 AM, Andreas Pieber wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I still think Hook is the best name (since the EDB is kind of
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> SCM
>>>>>>>>>>>>>>> and hook is the name typically used for the scripts
>>>>>>>>>>>>>>> interacting
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> the process there. Nevertheless my second favor would be
>>>>>>
>>>>>> listener,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> since I've other situations with a trigger... @ChristophGr
>>>>>>>>>>>>>>> what
>>>>>>
>>>>>> do
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> think about this? IIRC the Trigger name was invented by you.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Listeners is fine with me.
>>>>>>>>>>>>>> SCM-hooks can also change the content of e.g. the
>>>>>>>>>>>>>> commit-message.
>>>>>>>>>>>>>> Also
>>>>>>>>>>>>>> they can be executed _before_ an action.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well we can also define before and after hooks; and some of them
>>>>>>>>>>>>> might
>>>>>>>>>>>>> also be able to change values. TBH I don't see a problem with
>>>>>>
>>>>>> that,
>>>>>>>>>>>>>
>>>>>>>>>>>>> do
>>>>>>>>>>>>> you?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OK, after giving the code a second look and reading your
>>>>>>
>>>>>> detailed
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> descriptions I'm getting an idea of what you're planing the to
>>>>>>
>>>>>> (at
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> least I think so :-)). The question is: is there a way to
>>>>>>
>>>>>> provide
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> option to configure the similarity index in a way that you can
>>>>>>>>>>>>>>> adapt
>>>>>>>>>>>>>>> it without changing the code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes: Great, include it into the OpenEngSB per se
>>>>>>>>>>>>>>> No: Include it only in documentation and provide only a
>>>>>>>>>>>>>>> library
>>>>>>>>>>>>>>> (in a
>>>>>>>>>>>>>>> seperate labs-XXX proejct) and document how this library could
>>>>>>
>>>>>> be
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>> in hooks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Problem is, that the code relies on the EDB notifying the
>>>>>>
>>>>>> listeners
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> which requires the interfaces to be added to the API and some
>>>>>>
>>>>>> minor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> changes to the EDB.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry for not being clear on that point. Of course the API needs
>>>>>>
>>>>>> to
>>>>>>>>>>>>>
>>>>>>>>>>>>> be
>>>>>>>>>>>>> included; I'm rather talking about the other components
>>>>>>
>>>>>> (similarity
>>>>>>>>>>>>>
>>>>>>>>>>>>> checker, ...)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>> Andreas
>>>>>>>>>>>>>
>>>>>>>>>>>>>> kind regards,
>>>>>>>>>>>>>> christoph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think you answered those questions partly in previous posts;
>>>>>>>>>>>>>>> nevertheless can you summarize them here again to make the
>>>>>>>>>>>>>>> decision
>>>>>>>>>>>>>>> process clear for all?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you very much for your effort and kind regards,
>>>>>>>>>>>>>>> Andreas
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> According to Felix there should not be that many
>>>>>>>>>>>>>>>>>> problems with implementing them into the current EDB
>>>>>>>>>>>>>>>>>> infrastructure.
>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>> basic assumption is that the triggers present in the OSGI
>>>>>>>>>>>>>>>>>> registry
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>> existing (-->     no overhead). If there are triggers, they
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> used.
>>>>>>>>>>>>>>>>>> The triggers [2] themselves are only adapter to the
>>>>>>
>>>>>> similarity
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> index,
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> call the correct implementation based on service
>>>>>>>>>>>>>>>>>> properties.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Do I get it right that there is no implementation right now?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> yes, there is no actual implementation/"usage" in the EDB
>>>>>>>>>>>>>>>> right
>>>>>>>>>>>>>>>> now,
>>>>>>>>>>>>>>>> FMa
>>>>>>>>>>>>>>>> plans to look at it after his exam. (this Fr)
>>>>>>>>>>>>>>>> Should only require some minor changes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The current similarity index implementation contains an
>>>>>>
>>>>>> lucene
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> implementation, but it could be replaced with other (almost
>>>>>>>>>>>>>>>>>> certainly
>>>>>>>>>>>>>>>>>> faster
>>>>>>>>>>>>>>>>>> services) in the future. Currently there are 4 sample
>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> different index implementations. There was an idea to put
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>>>>> into config files an load them on the fly (similar to the
>>>>>>>>>>>>>>>>>> ConnectorDeployerService), but imho there are some
>>>>>>>>>>>>>>>>>> downsides/unsolved
>>>>>>>>>>>>>>>>>> problems.
>>>>>>>>>>>>>>>>>> - the index creation could use more advanced java code -->
>>>>>>>>>>>>>>>>>> problematic
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> store them in config files
>>>>>>>>>>>>>>>>>> - if i use hotdeploy for the index, there has to be some
>>>>>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the trigger (no real hotdeploy possible; you could use some
>>>>>>>>>>>>>>>>>> wiring
>>>>>>>>>>>>>>>>>> techniques, but i don't know if that would be too much
>>>>>>>>>>>>>>>>>> overhead)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The pros would be:
>>>>>>>>>>>>>>>>>> - hotdeploy
>>>>>>>>>>>>>>>>>> - no configuration code in the similarity service
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So overall: WDYT?
>>>>>>>>>>>>>>>>>> There is a features.xml[4].
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The plan was to maintain the similarity index [3] as part of
>>>>>>
>>>>>> the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> engsb.
>>>>>>>>>>>>>>>> The problem here is, how to handle the concrete
>>>>>>
>>>>>> implementations:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - should there be some sample implementations (like
>>>>>>
>>>>>> StandardIndex
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>> ComplexIndex), to show the functionality or should this be
>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>> documented
>>>>>>>>>>>>>>>> in the documentation.
>>>>>>>>>>>>>>>> - how should we handle the trigger -->     again should there
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>> dummy
>>>>>>>>>>>>>>>> implementations or only documentation
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Besides the current implementation i've another idea:
>>>>>>>>>>>>>>>> create concrete instances of the index in the Trigger (define
>>>>>>
>>>>>> the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>> methods addDocument(EDBObject c) and
>>>>>>>>>>>>>>>> buildQueryString(EDBObject
>>>>>>>>>>>>>>>> sample)
>>>>>>>>>>>>>>>> there) and maintain only the abstract similarity index
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> pro:
>>>>>>>>>>>>>>>> - configuration gets out of the similarity index package and
>>>>>>
>>>>>> into
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> concrete implementation of the hooks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> con:
>>>>>>>>>>>>>>>> - with the current setup the concrete index implementation
>>>>>>>>>>>>>>>> has
>>>>>>
>>>>>> to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> defined
>>>>>>>>>>>>>>>> twice (unless you merge the EDBHook Interfaces)
>>>>>>>>>>>>>>>> - when you are using different index definitions, all of them
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> defined in this hook -->     the hooks get more configuration
>>>>>>>>>>>>>>>> code/no
>>>>>>>>>>>>>>>> generalization (code reuse)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> if this is not clear I'll provide a quick prototype of this
>>>>>>>>>>>>>>>> "architecture"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ~Christoph
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Basically you code looks OK, but I don't get it where
>>>>>>>>>>>>>>>>> exactly
>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> would like to have our feedback. What do you plan to do with
>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>> hooks? Do we like to provide them as part of the engsb?
>>>>>>>>>>>>>>>>> *confused*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> kind regards,
>>>>>>>>>>>>>>>>> Andreas
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> best regards
>>>>>>>>>>>>>>>>>> Christoph
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>> https://github.com/chhochreiner/openengsb-framework/tree/edbtrigger
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [2] https://github.com/chhochreiner/EDBHook
>>>>>>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>>>>>> https://github.com/chhochreiner/similarityIndexPrototype
>>>>>>>>>>>>>>>>>> [4]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>
>>>>>> https://github.com/chhochreiner/similarityIndexPrototype/blob/master/src/main/filtered-ressources/features.xml
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>


Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/20/12 3:31 AM
IMHO the ErrorHook is almost useless. I don't know anyway what that
should do TBH. What we also need, to fulfill the needs of the similarity
checker would be:

commit(EKBCommit commit) throws EDBException{
     try {
        check(commit);
     } catch (Exception e) {
        similar = invokeAllOsgiServices(FindSimilar.class, a list of all
models where the check has failed because of specific errors);
        throw new EDBException("Incompatibles models which shall be
updated {models}. Maybe you meant {similar}.");
     }
     // rest of the commit part
}

Kind regards
Felix

Re: RFC: Similiarity index with trigger Andreas Pieber 3/20/12 3:51 AM
TBH I simply don't like the idea of integrating the idea of a
similarity check into the EDB; why not using the hooks as ChrstophGr
had drawn them but delegate more possibilities to the client.

E.g.

invokeAllOsgiServices(PreCommitHook.class,
allValuesToCommitAsReferenceListClientsCanModify) throws
AbortException, LogAndContinueException,
...otherControllingException...

Kind regards,
Andreas

Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/20/12 4:00 AM
I don't like it too, but exactly this feature is (at least for now) the
only reason why we discuss about this topic anyhow. As Richard (at least
I think he was it that begin with this feature) meant that they want it,
you said that you only want to provide this through such a hook system
since you don't want it in the core (what I understand perfectly). But
if we don't use it for that, then we can throw away the idea, at least
for now. Also we must find another way to provide this functionality.

Kind regards
Felix

Re: RFC: Similiarity index with trigger Andreas Pieber 3/20/12 4:19 AM
true, but couldn't you implement it using my latest approach?

Kind regards,
Andreas

Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/20/12 4:27 AM
I wouldn't know how. IMHO should the detection of errors stay in the
EDB, since I think it is a bad idea to let this job do by any component
which exports a specific service, which would espacially be a problem if
no such service exists. But only with the detection of errors, can the
similarity search be started. Other possibility would be to start the
detection of errors twice but that's not really good.

But from my point of view I don't know exactly what the problem with the
approach is with my previous thing:

commit(EKBCommit commit) throws EDBException{
    try {
       check(commit);
    } catch (Exception e) {
       similar = invokeAllOsgiServices(FindSimilar.class, a list of all models where the check has failed because of specific errors);
       throw new EDBException("Incompatibles models which shall be updated {models}. Maybe you meant {similar}.");
    }
    // rest of the commit part
}


In that way it would be possible that:
- if such a service is present in the OSGi environment, the error would
also return similar EDB objects.
- if such a service isn't present, the error would not append similar
EDB objects.

That would have the fealing of a plug-in for me. The only thing to
discuss here would be if there are other feature requests where this
approach would also be useful.

Kind regards,
Felix

Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/26/12 4:09 AM
Are there any news here?

Kind regards
Felix...
Re: RFC: Similiarity index with trigger Christoph Gritschenberger 3/26/12 4:21 AM
We (andreas and me) discussed this last wednesday.
We could define hook-behaviour similar to osgi weaving-hooks.
If a Hook throws a "EdbHookException" the action is aborted.
Any other Exception in a hook is printed to the log and ignored.

----------------------------------------------------------

invokeAllOsgiServices(PreCommit.class, edbCommit)
try{
        check(edbCommit)
} catch (Exception e){
        for(ErrorHook eh : allErrorHookServices){
                if(eh.onError(edbCommit, edbCommit)){
                        // check again
                }
        }
        throw e;
}

// commit

invokeAllOsgiServices(PostCommit.class, edbCommit)

-----------------------------------------------------------

WDYT?

kind regards,
christoph

>     > <felix.ma...@gmail.com <mailto:felix.ma...@gmail.com>>>     >>> <felix.ma...@gmail.com <mailto:felix.ma...@gmail.com>>>     <mailto:felix.ma...@gmail.com>>      wrote:


>     >>>>>>> We could introduce an ErrorHook "needSimilarModels", but I
>     don't know
>     >>>>>>> how to
>     >>>>>>> name that properly. Also something like that is very
>     specific. Maybe
>     >>>>>>> we
>     >>>>>>> should take a step back think about what our usecases are,
>     what we
>     >>>>>>> really
>     >>>>>>> need and what could be interessting in the future.
>     >>>>>>>
>     >>>>>>> Kind regards,
>     >>>>>>> Felix
>     >>>>>>>
>     >>>>>>> Am 2012-03-20 10:32, schrieb Andreas Pieber:
>     >>>>>>>
>     >>>>>>>> what about an error hook?
>     >>>>>>>>
>     >>>>>>>> Kind regards,
>     >>>>>>>> Andreas
>     >>>>>>>>
>     >>>>>>>> On Tue, Mar 20, 2012 at 10:29, Felix Mayerhuber
>     >>>>>>>> <felix.ma...@gmail.com
>     >>>>>>>>>>>>> <christoph.gritschenberger@​gmail.com>     >>>>>>>>>>>>>>>> issues.openengsb.org <http://issues.openengsb.org>>     <https://github.com/chhochreiner/EDBHook>
>     >>>>>>>>>>>>>>>>> [3] https://github.com/​chhochreiner/​
>     similarityIndexPrototype

>     <https://github.com/chhochreiner/similarityIndexPrototype>
>     >>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>> On Monday, March 19, 2012 10:22:22 AM UTC+1,
>     Andreas Pieber
>     >>>>>>>>>>>>>>>>> wrote:
>     >>>>>>>>>>>>>>>>>> Hey
>     >>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>> On Mon, Mar 19, 2012 at 09:45, Christoph
>     Gritschenberger
>     >>>>>>>>>>>>>>>>>> <christoph.gritschenberger@​gmail.com
>     <mailto:christoph.gritschenberger@gmail.com>>          wrote:
>     >>>>>>>>>>>>>>>>>>>>>> kind regards,
>     >>>>>>>>>>>>>>>>>>>>>> Andreas
>     >>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>> best regards
>     >>>>>>>>>>>>>>>>>>>>>>> Christoph
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>> [1]
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>> https://github.com/​chhochreiner/openengsb-​
>     framework/tree/edbtrigger
>     <https://github.com/chhochreiner/openengsb-framework/tree/edbtrigger>
>     >>>>>>>>>>>>>>>>>>>>>>> [2] https://github.com/​chhochreiner/EDBHook
>     <https://github.com/chhochreiner/EDBHook>
>     >>>>>>>>>>>>>>>>>>>>>>> [3]
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>> https://github.com/​chhochreiner/​
>     similarityIndexPrototype
>     <https://github.com/chhochreiner/similarityIndexPrototype>
>     >>>>>>>>>>>>>>>>>>>>>>> [4]
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>> https://github.com/​chhochreiner/​
>     similarityIndexPrototype/blob/​master/src/main/filtered-​
>     ressources/features.xml
>     <https://github.com/chhochreiner/similarityIndexPrototype/blob/master/src/main/filtered-ressources/features.xml>
>     >>>>>>>>>>>>>>>>>>>>>>>
>


Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/26/12 4:39 AM
Hi,

sounds good, for the pre and post commit stuff. But for the usecase, for
which the whole thing was intended, I'm not that sure about it. Problem
is: Errors could be of any type and an ErrorHook can handle any type of
error. In the way you posted it, the ErrorHookServices would try to
repair the error and then the commit would be checked again. But the
thing we need for the usecase is: if an error of that specific type
occurs and a similarity service is present, then enrich the exception
that is thrown back to the user with similar objects. If such a service
is not present, return the exception back unenriched. It's quite a
specific thing. But we could of course do it like that and introduce a
new service which only does this specific thing and catch both types and
handle each of them separately. Another way would be to let the called
errorhook append stuff to the exception that will be thrown in the EDB.

But we should think about this ErrorHooks anyway: How many errors in the
EDB could be managed by a service autonomously? The only exceptions that
can occur in the check-phase (at least now) are:
- deletion of a non existing model
- insertion of an already existing model
- update of a model that is not existing
- version conflict

IMHO there is no need and usecase for ErrorHooks, at least I don't see
it. But we need that specific usecase (even though it's most certainly
only a marketing thing which no company would use).

Kind regards
Felix

Re: RFC: Similiarity index with trigger Christoph Gritschenberger 3/26/12 4:42 AM
Ah of course, now I remember...
We thought it could work this way:

The Error-hook may return either:
* a new edbcommit-object --> recheck
* a new exception --> throw that one
* null --> nothing...

WDYT?

kind regards,
christoph

Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/26/12 4:49 AM
That would be a possibility. But one thing remain in that way: the
similarity checker has to check the whole commit again to find out what
the errors are. That mean that the error detection algorithm would be
1:1 in the EDB and in the similarity checker. If that is no problem for
you, we can do it like that. Or we have to find a way to tell the
ErrorHook what exactly was the problem and which objects are involved.

Kind regards,
Felix

>>>>       <http...

Re: RFC: Similiarity index with trigger Christoph Gritschenberger 3/26/12 4:50 AM
We could include it in the Exception-object

kind regards,
christoph

>>>>>       >>>>>>>>>>>>>>>>>>>>...

Re: RFC: Similiarity index with trigger Felix Mayerhuber 3/26/12 4:56 AM
Mhm. Sounds reasonable. But we have to think about how to do that
properly. e.g. a list of every error type or something. But we can do it
like that :-)

Kind regards,
Felix

>>>>>>       ...

Re: RFC: Similiarity index with trigger Christoph Hochreiner 4/2/12 9:16 AM
are there any news on this topic or is it still in discussion?

kind regards
Christoph
...
Re: RFC: Similiarity index with trigger Felix Mayerhuber 4/4/12 1:50 PM
Unfortunately I've again a problem with that. Like already posted: If we pass the EKBCommit to the error-hook, the error-hook has again to check where the errors are. And this is a problem since the both error detection algorithms maybe not the same. Or should we pass the exception to the error hook too?

Kind regards
Felix...
Re: RFC: Similiarity index with trigger Andreas Pieber 4/4/12 3:09 PM

Yep, imho the error hook should get everything as detailed as we have it. The security implementation can root out the danger of such an approach at another place.

Kind regards,
Andreas

>>>>>>        >>>>>>>>>>>>>>>    Hey,
>>>>>>        >>>>>>>>>>>>>>>
>>>>>>        >>>>>>>>>>>>>>>    Maybe the separation is not necessary. One
>>>>>> thing I could

...
More topics »