P.S. I'm concerned with speed now, because before too long it will have a lot more data to deal with.
I think when that occurs the best solution will be to upgrade to 4.1
Also.. in the most data heavy case of what it exports I could actually get away with using the nodeFactory, but that will require duplicating the code for nodes as opposed to documents, or as @slace suggests: implementing a factory to generate adaper/proxy classes instead
P.S. I'm concerned with speed now, because before too long it will have a lot more data to deal with.
I think when that occurs the best solution will be to upgrade to 4.1
Also.. in the most data heavy case of what it exports I could actually get away with using the nodeFactory, but that will require duplicating the code for nodes as opposed to documents, or as @slace suggests: implementing a factory to generate adaper/proxy classes instead
Performant way to get all a Document's Descendants
I've created this method to get all descendants of a given document.
But it's VERY slow, 10 seconds! is there a faster way to do this?
It doesn't have to be fast because it's for an admin report.
However it's very slow and it's got less than 100 records in that branch of the tree.
The Document API is insanely slow in v4.0.x. It has been dramatically improved in 4.1.
The only way to speed it up is to build your own caching, put it into a singleton so it's maintained for live of the app pool.
It'll give you good performance if you're running it multiple times.
It's probably only going to run once a month. :-)
P.S. I'm concerned with speed now, because before too long it will have a lot more data to deal with.
I think when that occurs the best solution will be to upgrade to 4.1
Also.. in the most data heavy case of what it exports I could actually get away with using the nodeFactory, but that will require duplicating the code for nodes as opposed to documents, or as @slace suggests: implementing a factory to generate adaper/proxy classes instead
P.S. I'm concerned with speed now, because before too long it will have a lot more data to deal with.
I think when that occurs the best solution will be to upgrade to 4.1
Also.. in the most data heavy case of what it exports I could actually get away with using the nodeFactory, but that will require duplicating the code for nodes as opposed to documents, or as @slace suggests: implementing a factory to generate adaper/proxy classes instead
Depending on what data you actually require it might be possible to just query the database for path which contains your start id
is working on a reply...