4:50 p.m.
[ http://jira.jboss.com/jira/browse/DNA-160?page=all ]
Randall Hauch updated DNA-160:
------------------------------
Summary: Create pluggable merge processor interface encapsulating the logic of how
to merge multiple nodes into one node (was: Create pluggable merge processor that
contains the logic of how to merge multiple nodes into one node)
Description:
A FederatedRepository instance should use a MergeProcessor implementation to actually do
all the merging operations; the FederatedRepository is then responsible for managing the
integrated repository (cache), adhering to the cache policies, making the requests to the
sources, calling the MergeProcessor, and then storing the merged node back in the cache.
The merging operations should include both reads and writes, and will need access to the
previous merge plan produced by the node. In fact, the merge operation may need to add
merge-processor-specific information to the merge plan so that it can reuse that
information at a later time.
It is very likely that the merge logic will evolve significantly over time, and that some
uses of DNA may even require their own (perhaps optimized) processing logic. I believe
there is even an opportunity to provide a Drools-based processor that uses rules to
perform the work. This obviously won't be the first implementation, but could be one
of the most powerful and capable processor implementations.
was:
A FederatedRepository instance should use a MergeProcessor implementation to actually do
all the merging operations; the FederatedRepository is then responsible for managing the
integrated repository (cache), adhering to the cache policies, making the requests to the
sources, calling the MergeProcessor, and then storing the merged node back in the cache.
It is very likely that the merge logic will evolve significantly over time, and that some
uses of DNA may even require their own (perhaps optimized) processing logic. I believe
there is even an opportunity to provide a Drools-based processor that uses rules to
perform the work. This obviously won't be the first implementation, but could be one
of the most powerful and capable processor implementations.
Create pluggable merge processor interface encapsulating the logic of
how to merge multiple nodes into one node
---------------------------------------------------------------------------------------------------------------
Key: DNA-160
URL: http://jira.jboss.com/jira/browse/DNA-160
Project: DNA
Issue Type: Sub-task
Components: Federation
Reporter: Randall Hauch
Assigned To: Randall Hauch
Fix For: 0.2
A FederatedRepository instance should use a MergeProcessor implementation to actually do
all the merging operations; the FederatedRepository is then responsible for managing the
integrated repository (cache), adhering to the cache policies, making the requests to the
sources, calling the MergeProcessor, and then storing the merged node back in the cache.
The merging operations should include both reads and writes, and will need access to the
previous merge plan produced by the node. In fact, the merge operation may need to add
merge-processor-specific information to the merge plan so that it can reuse that
information at a later time.
It is very likely that the merge logic will evolve significantly over time, and that some
uses of DNA may even require their own (perhaps optimized) processing logic. I believe
there is even an opportunity to provide a Drools-based processor that uses rules to
perform the work. This obviously won't be the first implementation, but could be one
of the most powerful and capable processor implementations.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira