manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Wright (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CONNECTORS-1549) Include and exclude rules order lost
Date Thu, 18 Oct 2018 22:34:00 GMT

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

Karl Wright commented on CONNECTORS-1549:
-----------------------------------------

Hi [~julienFL]

Sorry for the delay.

First note that you can always use the order-preserving form even if MCF outputs the JSON
in the other "sugary" form.  So this should unblock you.

Second, I'm looking at the code that generates the output in Configuration.java:

{code}
    // The new JSON parser uses hash order for object keys.  So it isn't good enough to just
detect that there's an
    // intermingling.  Instead we need to the existence of more that one key; that implies
that we need to do order preservation.
    String lastChildType = null;
    boolean needAlternate = false;
    int i = 0;
    while (i < getChildCount())
    {
      ConfigurationNode child = findChild(i++);
      String key = child.getType();
      List<ConfigurationNode> list = childMap.get(key);
      if (list == null)
      {
        // We found no existing list, so create one
        list = new ArrayList<ConfigurationNode>();
        childMap.put(key,list);
        childList.add(key);
      }
      // Key order comes into play when we have elements of different types within the same
child. 
      if (lastChildType != null && !lastChildType.equals(key))
      {
        needAlternate = true;
        break;
      }
      list.add(child);
      lastChildType = key;
    }
        
    if (needAlternate)
    {
      // Can't use the array representation.  We'll need to start do a _children_ object,
and enumerate
      // each child.  So, the JSON will look like:
      // <key>:{_attribute_<attr>:xxx,_children_:[{_type_:<child_key>, ...},{_type_:<child_key_2>,
...}, ...]}
...
{code}

The (needAlternate) clause is the one that writes the specification in the verbose form. 
The logic seems like it would detect any time there's a subtree with a different key under
a given level and set "needAlternate".  I'll stare at it some more but right now I'm having
trouble seeing how this fails.


> Include and exclude rules order lost
> ------------------------------------
>
>                 Key: CONNECTORS-1549
>                 URL: https://issues.apache.org/jira/browse/CONNECTORS-1549
>             Project: ManifoldCF
>          Issue Type: Bug
>          Components: API, JCIFS connector
>    Affects Versions: ManifoldCF 2.11
>            Reporter: Julien Massiera
>            Assignee: Karl Wright
>            Priority: Critical
>         Attachments: image-2018-10-18-18-28-14-547.png, image-2018-10-18-18-33-01-577.png,
image-2018-10-18-18-34-01-542.png
>
>
> The include and exclude rules that can be defined in the job configuration for the JCIFS
connector can be combined and the defined order is really important.
> The problem is that when one retrieve the job configuration as a json object through
the API, the include and exclude rules are splitted in two diffrent arrays instead of one
(one for each type of rule). So, the order is completely lost when one try to recreate the
job thanks to the API and the JSON object. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message