[
https://issues.apache.org/jira/browse/CONNECTORS-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201204#comment-16201204
]
Karl Wright edited comment on CONNECTORS-1356 at 10/11/17 11:43 PM:
--------------------------------------------------------------------
[~piergiorgioluc...@gmail.com], you should return MODEL_ADD_CHANGE_DELETE
*only* if your seeding query returns documents that have been deleted in
addition to those that have been added or changed. If your seeding query does
not return deleted documents, then maybe MODEL_ADD_CHANGE is appropriate, if
the seeding query is the only way new or changed documents can be discovered.
But if new documents can be discovered by scanning crawled documents, then
MODEL_CHAINED_ADD_CHANGE is the right model.
I've been looking for a connector that uses straight MODEL_ADD_CHANGE where
there's an integration test, and I haven't found one yet. But
MODEL_CHAINED_ADD_CHANGE is very similar and the file system connector uses it.
The current trunk Cmis connector uses MODEL_CHAINED_ADD_CHANGE too.
The web and rss connectors use MODEL_ALL, which stipulates that the seeding
query return all documents in the set, so these won't help.
So, this is how I would debug this:
(1) Try running the file system connector integration tests. Do these pass?
(2) If they don't, figure out what changes have been made to the framework in
your branch that aren't on trunk.
(3) If these tests pass, try changing your connector model to
MODEL_CHAINED_ADD_CHANGE. If that *does* work, maybe the framework is doing
something wrong with the unchained models, and I'll have to look into that. In
that case it would help if you could describe to me all ways that the CMIS
connector discovers added and changed documents.
Thanks!
was (Author: kwri...@metacarta.com):
[~piergiorgioluc...@gmail.com], you should return MODEL_ADD_CHANGE_DELETE
*only* if your seeding query returns documents that have been deleted in
addition to those that have been added or changed. If your seeding query does
not return deleted documents, then maybe MODEL_ADD_CHANGE is appropriate, if
the seeding query is the only way new or changed documents can be discovered.
But if new documents can be discovered by scanning crawled documents, then
MODEL_CHAINED_ADD_CHANGE is the right model.
I've been looking for a connector that uses straight MODEL_ADD_CHANGE where
there's an integration test, and I haven't found one yet. But
MODEL_CHAINED_ADD_CHANGE is very similar and the file system connector uses it.
The current trunk Cmis connector uses MODEL_CHAINED_ADD_CHANGE too.
The web and rss connectors use MODEL_ALL, which stipulates that the seeding
query return all documents in the set, so these won't help.
So, this is how I would debug this:
(1) Try running the file system connector integration tests. Do these pass?
(2) If they don't, figure out what changes have been made to the framework in
your branch that aren't on trunk.
(3) If these tests pass, try changing your connector model to
MODEL_CHAINED_ADD_CHANGE. If that *does* work, maybe the framework is doing
something wrong with the unchained models, and I'll have to look into that. It
would help if you
Thanks!
> Initial implementation of the CMIS Output Connector
> ---------------------------------------------------
>
> Key: CONNECTORS-1356
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1356
> Project: ManifoldCF
> Issue Type: Task
> Components: CMIS Output Connector
> Reporter: Piergiorgio Lucidi
> Assignee: Piergiorgio Lucidi
> Fix For: ManifoldCF 2.9
>
> Attachments: CMISOutputConnectorSettings.png,
> ResultWithTimestampTreeOnTargetRepo.png, SourceRepoFolder.png
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> After we have discussed about the possibility to have some output connector
> dedicated to migrate contents from a specific repo to another one, this is
> the first implementation for the CMIS protocol.
> The discussion is the following:
> http://mail-archives.apache.org/mod_mbox/manifoldcf-dev/201611.mbox/%3CCAEO2op-bjNv4xSTPwGN%3DV2v47Sy8d%2BwKNtd1RpV2PC85y_JAgw%40mail.gmail.com%3E
> The main scenario is migrate contents from any repository type to a
> CMIS-compliant repo.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
