I also see the same problem.
Interestingly it seems some attributes of the ScriptNode object are retrieved very quickly, but some are retrieved very slowly. Why is this, and is there no way to programmatically look at individual properties on a node array without waiting almost 100 milliseconds for EACH property examined? Looking at the results below, to view a node property it takes a full two orders of magnitude longer than viewing say, the node type.
(For testing I've used a sample URL executable script placed in Data Dictionary/Scripts
It seems like the properties array just isn't loaded up into lucene result list of nodes.
Interestingly it seems some attributes of the ScriptNode object are retrieved very quickly, but some are retrieved very slowly. Why is this, and is there no way to programmatically look at individual properties on a node array without waiting almost 100 milliseconds for EACH property examined? Looking at the results below, to view a node property it takes a full two orders of magnitude longer than viewing say, the node type.
(For testing I've used a sample URL executable script placed in Data Dictionary/Scripts
// In my test case, this query returns 394 nodes.
var query = "TYPE:\"{http://www.alfresco.org/model/content/1.0}content\"";
var total = "";
var out = "";
if( query != null && query.length > 0 ) {
var result = search.luceneSearch(query); // fast
total = result.length;
for (i=0;i<result.length;i++) {
// let's take a look at how long the script takes on various ScriptNode object attributes.
// I uncommented each of these one by one and measured how long it took to print out that
// individual ScriptNode attribute:
//out += result[i].id +"<br>"; // ~ 0.3 seconds on 394 nodes.
//out += result[i].nodeRef +"<br>"; // ~ 0.3 seconds on 394 nodes.
//out += result[i].displayPath +"<br>"; // ~ 0.6 seconds on 394 nodes.
//out += result[i].qnamePath +"<br>"; // ~ 0.4 seconds on 394 nodes.
//out += result[i].isLocked() +"<br>"; // ~ 0.3 seconds on 394 nodes.
//out += result[i].type +"<br>"; // ~ 0.4 seconds on 394 nodes.
//out += result[i].parent.id +"<br>"; // ~ 0.3 seconds on 394 nodes.
//out += result[i].isCategory +"<br>"; // ~ 0.2 seconds on 394 nodes.
//out += result[i].aspects +"<br>"; // ~ 0.4 seconds on 394 nodes. !!! fast.
//out += result[i].size +"<br>"; // ~ 27.4 seconds on 394 nodes.
//out += result[i].url +"<br>"; // ~ 28.1 seconds on 394 nodes.
//out += result[i].downloadUrl +"<br>"; // ~ 28.2 seconds on 394 nodes.
//out += result[i].name +"<br>"; // ~ 27.8 seconds on 394 nodes.
}
}
out += "<br><br>";
out += "<b>query:</b> "+query+"<br>";
out += "<b>total:</b> "+total+"<br>";
out;It seems like the properties array just isn't loaded up into lucene result list of nodes.
The Alfresco Lucene API can perform some sorting for you, and we provide access to that through the scripting API:
If you need to sort by more than one column then the Script API does not yet provide this. But i can easily add it for Alfresco 3.2 since it has now been requested
The reason some properties take longer than others to retrieve is that some properties are easily resolvable from data already cached on the ScriptNode instance - and some data must be retrieved directly from the repository (and then cached). Accessing individual properties of 1000's of nodes via the ScriptNode API is not going to be as fast as writing some Java code to do it - as the ScriptNode API calls must always pass through all levels of Permissions and Public Service Interceptors etc. for each call (Java code does not always need to do this…)
Thanks,
Kevin
Array luceneSearch(string query, string sortColumn, boolean asc)
Returns an array of ScriptNode satisfying the search criteria sorted by the specified sortColumn (the property name to sort on) and asc (true => ascending order, false => descending order). For example var nodes = search.luceneSearch("TEXT:alfresco", "@cm:modified", false);
If you need to sort by more than one column then the Script API does not yet provide this. But i can easily add it for Alfresco 3.2 since it has now been requested
The reason some properties take longer than others to retrieve is that some properties are easily resolvable from data already cached on the ScriptNode instance - and some data must be retrieved directly from the repository (and then cached). Accessing individual properties of 1000's of nodes via the ScriptNode API is not going to be as fast as writing some Java code to do it - as the ScriptNode API calls must always pass through all levels of Permissions and Public Service Interceptors etc. for each call (Java code does not always need to do this…)
Thanks,
Kevin
Thanks for the reply, Kevin!
http://wiki.alfresco.com/wiki/3.0_JavaScript_API#Native_Java_API_Access
Thanks for your help!
Dave
The Alfresco Lucene API can perform some sorting for you, and we provide access to that through the scripting API:Ah, this was used at first but was not returning correct results with tokenized fields, e.g. cm:title because each token was being considered separately.Array luceneSearch(string query, string sortColumn, boolean asc)
Returns an array of ScriptNode satisfying the search criteria sorted by the specified sortColumn (the property name to sort on) and asc (true => ascending order, false => descending order). For example var nodes = search.luceneSearch("TEXT:alfresco", "@cm:modified", false);
If you need to sort by more than one column then the Script API does not yet provide this. But i can easily add it for Alfresco 3.2 since it has now been requestedThat's great- thanks Kevin- Though while we're prioritizing features for Alfresco 3.2, I'd place these above multi-column sort as they are likely even more common needs:
- Sorting correctly on a tokenized field
- Returning only a specified page worth of all result data (e.g. results 21 through 30)
- Perhaps with the now small set of data thanks to the above paging, all properties of those 10 nodes can be fetched & cached? (Although 100ms X 10 isn't quite as terrible.)
The reason some properties take longer than others to retrieve is that some properties are easily resolvable from data already cached on the ScriptNode instance - and some data must be retrieved directly from the repository (and then cached). Accessing individual properties of 1000's of nodes via the ScriptNode API is not going to be as fast as writing some Java code to do it - as the ScriptNode API calls must always pass through all levels of Permissions and Public Service Interceptors etc. for each call (Java code does not always need to do this…)In order to tap into the power of the Java API, from the webscript would we call the Java API like this? (Or is there another more standard way?)
http://wiki.alfresco.com/wiki/3.0_JavaScript_API#Native_Java_API_Access
Thanks for your help!
Dave
