Proposal: Remove the need for "parent type"

“Parent type” crops up in several places - girder_cli for one currently requires this flag and for collection download reports “download command only accepts parent-type of folder”. But it’s not like you really need it - there will never be a Mongo ID that matches both the collection and folder models. I suppose it is theoretically possible but not practically possible.

On a major version update can we revisit this to perhaps merge both concepts into one model (or a folder model with collection as an extension/subclass)? Collections (1) don’t have parents and (2) have extra metadata like quotas, but I believe otherwise behave like folders. The Girder UI could stay the same (i.e. they are still named Collections and Folders), and the parentType parameter could still be supported as a validation check of the expected type, but if absent, it queries a single folder/collection Mongo collection and returns whatever matches. Folders would also no longer need to keep track of whether they are in a folder or collection - they would just have a parent id.

I’m happy to hear the drawbacks of this approach but I feel it’s worth considering.

[manthey]

On some API endpoints, we have a small set of possible models that the parent type can be. We could make it so if the parent type is not specified, that limited list of models is checked before we reject the passed ID.

[zachmullen]

I like your first proposal:

you could simply define a collection as any folder without a parent

It doesn’t destroy any of our existing domain models that we’ve been presenting to users, and would simplify our server and client logic. What I find problematic is that it would actually necessitate your second proposal of removing the feature of user data space entirely. I think that’s actually a nice feature of Girder.