-
Notifications
You must be signed in to change notification settings - Fork 3
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
Feature/30 enums #31
Feature/30 enums #31
Conversation
47b2695
to
d4bd6d8
Compare
To check:
|
2097cae
to
007cf62
Compare
I think we want to not assume relation IDs are always the same and can be project-defined. Endpoint docs are legacy and should be updated. Relation IDs should be fetched and cached once per-project. |
007cf62
to
0ce8fe6
Compare
Rebased on master after #27 |
- Use in export application - Add convenience methods
- Move more functionality onto enum to make it more interoperable with string - CoordinateTransformer, ProjectStack use StackOrientation internally
Makes sense. In that case, I guess it'd be better to define the enum using the string representations here https://github.com/catmaid/CATMAID/blob/master/django/applications/catmaid/control/connector.py#L35 , and then make a method/function which returns a list of The enum could be scrapped entirely if we're treating the relations as dynamic, but that doesn't quite feel right either. |
0ce8fe6
to
b478b5e
Compare
Rebased on master after #28 |
@aschampion done. Adds some complexity but I think it's the best way to do it while still keeping the nice bits of enums. It'll break when different connector types are added but catpy was always going to be brittle to changes in CATMAID. |
Relation ID mappings may be different between projects, and so cannot be stored in an enum. The RelationIdentifier converts IDs to the enum form and back.
121e5b9
to
1907fc5
Compare
resolves #30