Hi Marcel, I uploaded all the source to github along with a summary spreadsheet. I would appreciate any time you have to review.
https://github.com/Domenic-Ansys/Jackrabbit2-Oak-Tests As you stated the move is a non goal, but in comparison to Jackrabbit 2 I am also finding in my tests that create, update, and copy are all faster in Jackrabbit 2 (10k nodes). Any input would be appreciated... Also, will MySql will not be listed as "Experimental" at some point? Thanks, Domenic -----Original Message----- From: Marcel Reutegger [mailto:[email protected]] Sent: Thursday, March 31, 2016 6:14 AM To: [email protected] Subject: Re: Jackrabbit 2.10 vs Oak 1.2.7 Hi Domenic, On 30/03/16 14:34, "Domenic DiTano" wrote: >"In contrast to Jackrabbit 2, a move of a large subtree is an expensive >operation in Oak" >So should I avoid doing a move of a large number of items using Oak? >If we are using Oak then should we avoid operations with a large number >of items in general? In general it is fine to have a large change set with Oak. With Oak you can even have change sets that do not fit into the heap. > As a FYI - there are other benefits for us to move to Oak, but our >application uses executes JCR operations with a large number of items >quite often. I am worried about the performance. > >The move method is pretty simple - should I be doing it differently? > >public static long moveNodes(Session session, Node node, String >newNodeName) >throws Exception{ > long start = System.currentTimeMillis(); > session.move(node.getPath(), "/"+newNodeName); > session.save(); > long end = System.currentTimeMillis(); > return end-start; >} No, this is fine. As mentioned earlier, with Oak a move operation is not cheap and is basically implemented as copy to new location and delete at the old location. A cheap move operation was considered a non-goal when Oak was designed: https://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackr a bbit%203 Regards Marcel
