[ 
https://issues.apache.org/jira/browse/CONNECTORS-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931517#comment-16931517
 ] 

Markus Schuch edited comment on CONNECTORS-1566 at 9/17/19 2:53 PM:
--------------------------------------------------------------------

[~kwri...@metacarta.com] i do not understand how my problem is related to the 
categories volume (ID 2004).
My problem is, that the connector does not find sub items below the enterprise 
workspace, which has indeed the ID 2000.

The behaviour we encounter is very exactly described here: 
https://www.tek-tips.com/viewthread.cfm?qid=1785052

{{where1=("OTParentID":2000 AND ("OTSubType":0 OR "OTSubType":202 OR 
"OTSubType":136))}}

does not find any items, but

{{where1=("OTParentID":2000)}}

does.

As stated in the mentioned tek-tips forum, having boolean operators in the 
query breaks it.
Our livelink content server runs with version 16.2.8

With Content Server 16.2.2 the following change was introduced (took from the 
official release notes)
{quote}
The behavior when searching for “any words” or “all words” in advanced search 
has been
changed to ignore Boolean operators (such as “and”, “or”, “not”) and treat them 
as keywords.
This makes the behavior consistent with other search operators. Depending on 
configuration,
this may also change the default search bar behavior
{quote}

And actually the solution desribed in the tek-tips forum works for us:

{{where1=("OTParentID":2000 AND ("OTSubType":0 OR "OTSubType":202 OR 
"OTSubType":136))&lookfor1=complexquery}}

returns the items in below the Enterprise Workspace root.

So {{lookfor1=complexquery}} does the trick in our case. The funny thing is, 
that we have this parameter already in one place in the connector.


was (Author: schuchm):
[~kwri...@metacarta.com] i do not understand how my problem is related to the 
categories volume (ID 2004).
My problem is, that the connector does not find sub items below the enterprise 
workspace, which has indeed the ID 2000.

The behaviour we encounter is very exactly described here: 
https://www.tek-tips.com/viewthread.cfm?qid=1785052

{{where1=("OTParentID":2000 AND ("OTSubType":0 OR "OTSubType":202 OR 
"OTSubType":136))}}

does not find any documents, but

{{where1=("OTParentID":2000)}}

does.

As stated in the mentioned tek-tips forum, having boolean operators in the 
query breaks it.
Our livelink content server runs with version 16.2.8

With Content Server 16.2.2 the following change was introduced (took from the 
official release notes)
{quote}
The behavior when searching for “any words” or “all words” in advanced search 
has been
changed to ignore Boolean operators (such as “and”, “or”, “not”) and treat them 
as keywords.
This makes the behavior consistent with other search operators. Depending on 
configuration,
this may also change the default search bar behavior
{quote}

And actually the solution desribed in the tek-tips forum works for us:

{{where1=("OTParentID":2000 AND ("OTSubType":0 OR "OTSubType":202 OR 
"OTSubType":136))&lookfor1=complexquery}}

returns the items in below the Enterprise Workspace root.

So {{lookfor1=complexquery}} does the trick in our case. The funny thing is, 
that we have this parameter already in one place in the connector.

> Develop CSWS connector as a replacement for deprecated LiveLink LAPI connector
> ------------------------------------------------------------------------------
>
>                 Key: CONNECTORS-1566
>                 URL: https://issues.apache.org/jira/browse/CONNECTORS-1566
>             Project: ManifoldCF
>          Issue Type: Task
>          Components: LiveLink connector
>    Affects Versions: ManifoldCF 2.12
>            Reporter: Karl Wright
>            Assignee: Karl Wright
>            Priority: Major
>             Fix For: ManifoldCF 2.14
>
>         Attachments: OTCS_IIS.png, OTCS_Tomcat.png, chrome_cgfC00ujx7.png
>
>
> LAPI is being deprecated.  We need to develop a replacement for it using the 
> ContentServer Web Services API.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Reply via email to