Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Date: Wed, 4 Mar 2015 16:50:04 +0000 (UTC)
From: "Nicolas Brandt (JIRA)" <jira@apache.org>
To: dev@chemistry.apache.org
Message-ID: <JIRA.12779438.1425487746000.76395.1425487804522@Atlassian.JIRA>
In-Reply-To: <JIRA.12779438.1425487746000@Atlassian.JIRA>
References: <JIRA.12779438.1425487746000@Atlassian.JIRA>
 <JIRA.12779438.1425487746469@arcas>
Subject: [jira] [Created] (CMIS-896) Improve how JSON response of CMIS query
 function is built
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Nicolas Brandt created CMIS-896:
-----------------------------------

             Summary: Improve how JSON response of CMIS query function is built
                 Key: CMIS-896
                 URL: https://issues.apache.org/jira/browse/CMIS-896
             Project: Chemistry
          Issue Type: Improvement
          Components: opencmis-server
    Affects Versions: OpenCMIS 0.12.0
            Reporter: Nicolas Brandt
            Priority: Minor


JSON responses of CMIS queries seems to be built in an inefficient way.

{code:java|title=org.apache.chemistry.opencmis.commons.impl.JSONConverter.java}
    /**
     * Converts a bag of properties.
     */
    public static JSONObject convert(final Properties properties, final String objectId, final TypeCache typeCache,
            final PropertyMode propertyMode, final boolean succinct, final DateTimeFormat dateTimeFormat) {
        if (properties == null) {
            return null;
        }

        // get the type
        TypeDefinition type = null;
        if (typeCache != null) {
            PropertyData<?> typeProp = properties.getProperties().get(PropertyIds.OBJECT_TYPE_ID);
            if (typeProp instanceof PropertyId) {
                String typeId = ((PropertyId) typeProp).getFirstValue();
                if (typeId != null) {
                    type = typeCache.getTypeDefinition(typeId);
                }
            }

            if (type == null && objectId != null && propertyMode != PropertyMode.CHANGE) {
                type = typeCache.getTypeDefinitionForObject(objectId);
            }
        }

        JSONObject result = new JSONObject();

        for (PropertyData<?> property : properties.getPropertyList()) {
            assert property != null;
            assert property.getId() != null;

            PropertyDefinition<?> propDef = null;
            if (typeCache != null) {
                propDef = typeCache.getPropertyDefinition(property.getId());
            }
            if (propDef == null && type != null) {
                propDef = type.getPropertyDefinitions().get(property.getId());
            }
            if (propDef == null && typeCache != null && objectId != null && propertyMode != PropertyMode.CHANGE) {
                typeCache.getTypeDefinitionForObject(objectId);
                propDef = typeCache.getPropertyDefinition(property.getId());
            }

            String propId = (propertyMode == PropertyMode.QUERY ? property.getQueryName() : property.getId());
            if (propId == null) {
                throw new CmisRuntimeException("No query name or alias for property '" + property.getId() + "'!");
            }
            result.put(propId, convert(property, propDef, succinct, dateTimeFormat));
        }

        return result;
    }

{code}

According to the quoted source code, building the JSON response of query {{select cmis:objectId, cmis:name from cmis:document}} requires to call the function ObjectService.getObjectById per each row returned.
When the query returns 1000 rows and the CMIS server is backed with a database it causes a significant performance slowdown.

For example with the two following queries (each of them returns 1000 rows):
 bq. select * from cmis:document
 bq. select cmis:objectId, cmis:name from cmis:document

The second one is more than 5x slower than the first one.

A solution may be to add PropertyType and Cardinality informations into PropertyData objects, so it's no longer necessary to retrieve properties definitions.

I have attached a svn diff file with the changes.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)