Mailing-List: contact dev-help@manifoldcf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@manifoldcf.apache.org
Date: Wed, 11 Oct 2017 23:44:00 +0000 (UTC)
From: "Karl Wright (JIRA)" <jira@apache.org>
To: dev@manifoldcf.apache.org
Message-ID: <JIRA.13025895.1481016179000.34456.1507765440574@Atlassian.JIRA>
In-Reply-To: <JIRA.13025895.1481016179000@Atlassian.JIRA>
References: <JIRA.13025895.1481016179000@Atlassian.JIRA> <JIRA.13025895.1481016179305@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (CONNECTORS-1356) Initial implementation of
 the CMIS Output Connector
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 11 Oct 2017 23:44:05 -0000


    [ 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:
--------------------------------------------------------------------

[~piergiorgiolucidi@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: kwright@metacarta.com):
[~piergiorgiolucidi@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)