Whoops, didn't hit reply-to-all... figured I'd forward it to the list, in case anyone else is curious about this discussion...
No, the number of open files has nothing to do with the number of "transient" subcollections you've created. Please see the method:
MagmaRepositoryController>>filePoolSize: anInteger "Set the maximum number of simultaneously-open files that
Magma will have."
repository filePoolSize: anInteger
Ahhh yes, looks like the default value (at least for the repo I have) is 60 files... that'd probably do it (the max on seasidehosting is 64). Is there a safe minimum limit (obviously >0) to use? I'd be tempted to pick, say, 32.
BTW, is that setting documented somewhere? I've been going through the Swiki, but it's very likely I missed something along the way, and there may be other resources I'm not aware of.
Of course, for all that griping, the question is what to do about it.
Some options:
- stop using the "luxury" features that create subcollections
- Have you considered using #select: instead of #where:?
Unfortunately, I'm not sure I have a choice here. I have a MagmaCollection. I need to be able to extract items from the collection with multiple matching features (and so I have a variety of indexes defined), and then I need to be able to sort on any one of those columns.
As far as I can tell, the only solution to this is #where:, to get a reader using a conjuctive expression for the features I'm matching, followed by #sorted:makeDistinct: to get the sorting I need. It's not the most efficient, but I wasn't able to find another way to do it (I'm sure there are other options, but the doc on the Swiki didn't suggest any).
Then again, maybe I'm still looking at this through the lens of one far more experienced with relational databases, and there's a solution better suited to an OODBMS...
Anyway, thanks for the response!
Brett.