Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for multiple trees of the same type within a single discipline #4829

Closed
Tracked by #4640
grantfitzsimmons opened this issue Apr 24, 2024 · 1 comment · Fixed by #5036
Closed
Tracked by #4640
Assignees
Labels
1 - Request A request made by a member of the community 2 - Database/Schema Issues that are related to the underlying database and schema geospecify
Milestone

Comments

@grantfitzsimmons
Copy link
Member

This is one component of #4640

Please see the issue for a more detailed write-up with additional considerations.

Trees

Because the TaxonTreeDefID (FK to TaxonTreeDef) indicates which taxon tree definition contains the names associated with an object, adding support for MOTs requires a fundamental change in the scoping hierarchy in Specify.

We would need to add the ability to view and switch between several taxon trees in a single discipline.

Because the trees would need to share a common schema configuration, the model I propose is to have it so that every tree is specific to that discipline, so even if there are 3, 4, or more trees in a discipline, they cannot be accessed outside that discipline.

Screen.Recording.2024-03-12.at.12.20.11.PM.mov

It could be as simple as a picklist that switches between the tree definitions so that the user can edit and view all of the trees linked to the various objects in that collection.

Specify could return all object types in the current collection and show only the trees that are connected to types in that list.

@grantfitzsimmons grantfitzsimmons added 1 - Request A request made by a member of the community 2 - Database/Schema Issues that are related to the underlying database and schema geospecify labels Apr 24, 2024
@CarolineDenis CarolineDenis modified the milestones: 7.9.9, 7.9.7 Apr 25, 2024
@realVinayak
Copy link
Contributor

realVinayak commented Jun 2, 2024

regarding query builder backend, this can be very simply (and naively) accomplished by passing the object type and getting the appropriate treedef here:

treedef = get_treedef(query.collection, table.name)

Figure out why it will "just work". the above assumes that defitems cannot be shared (like same rank ITSELF wouldn't appear in two trees). Like if Kingdom is treedefitemid=1 in one treedef, it is also not treedefitemid=1 in another treedef. basically, how the trees in specify works currently (so no worries I believe)

BUT, I think that'll be inefficient. You can make it considerably more efficient (think why the above isn't) very simply, by including the objecttype equality to the join criterion (well, technically just the first node, but you get the point)
(

query = query.outerjoin(ancestor, ancestors[-1].ParentID == getattr(ancestor, ancestor._id))
)

^ofc that's for querying a specific tree. querying all trees at once is simpler (but I guess you can't say (any tree) -> species), like you could have (Fossil) -> species)

theoretically, doing something like (any tree) -> species is also straightforward (will think about perf impact). you could have an OR condition here (look up all treedefitemids which have species, put them in the OR below

treedefitem_param = sql.bindparam('tdi_%s' % query.param_count, value=treedef.treedefitems.get(name=tree_rank).id)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - Request A request made by a member of the community 2 - Database/Schema Issues that are related to the underlying database and schema geospecify
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants