Can we delete the odm2api/ODM1_1_1 code?

[valentinedwv]

Seems to not be maintained.

[emiliom]

I've wondered about that too; mainly about what it's there for if it's not ODM2 per se

[sreeder]

The odm1_1_1 code is intended to help map the odm2 tables into the odm1 schema. So that if someone has used the api to connect to an odm1 database they can seamlessly connect to an odm2 database. We developed this to try and support an odm2 database in our current structure of ODMToolsPython. There are a few key features, like relationships, that don't currently work. It is inactive because we have been focusing on getting the ODM2 interface working. The LikeODM1section creates the class mappings, and the ODM1_1_1 contains the services and queries. When we are done we should be able to run those same queries on an odm2 database.

[emiliom]

@sreeder, thanks for the explanation. It sounds like a useful functionality. But:

• Given that there are key features that don't currently work, I suggest at least moving it all into a separate branch soon and keeping it there for the time being.
• More broadly, this seems like a highly specialized capability that probably should be its own package/repository that uses odm2api, rather than a part of odm2api.

[valentinedwv]

Circular logic in the code ( I think). If this API is the base, and future versions of ODM tools will depend on it, then ODM2api can not have dependencies on ODMTools.

I would guess also, that I've mucked up the original code

[horsburgh]

The point is that we developed the first versions of ODM Tools Python based on ODM 1.1.1 - because ODM2 was not ready and we needed ODM Tools Python. Our desire is to have a single ODM Tools codebase that works with both ODM 1.1.1 and ODM2 databases. Our approach was to develop code that made time series data coming from an ODM2 database look the same as if it came from an ODM 1.1.1 database. This is obviously broken at the moment.

We're open to suggestions for how to go about getting ODM Tools Python to work with both ODM 1.1.1 and ODM2.

[emiliom]

We're open to suggestions for how to go about getting ODM Tools Python to work with both ODM 1.1.1 and ODM2.

I don't have any at this point :( Besides, I'm not familiar with the ODM Tools code base proper.

But I'll go back to my comments from a couple of days ago regarding the relationship of the ODM 1.1.1 code base with odm2api:

• Given that there are key features that don't currently work, I suggest at least moving it all into a separate branch soon and keeping it there -- and doing development there -- for the time being. That way the master and any dev branches off of it will remain cleaner.
• More broadly, this seems like a specialized capability that probably should be its own package/repository that uses odm2api, rather than being a part of odm2api. It probably shouldn't be core odm2api functionality. It's only of interest to ODM 1.x users; that's a very important user base, but I think it's better to keep odm2api leaner and entirely focused on ODM2. The ODM 1.1.1 stuff can more easily be split off into a separate package (and ODM2 github repo). Alternatively, in principle a plugin architecture could be developed for odm2api, but that's much more work up front.

[sreeder]

@emiliom @valentinedwv I am going to remove the ODM1 code from the repository, should I also remove the ODM2 folder and just put the models and services code straight into the odm2api folder, or do we want to keep the hierarchy?

[valentinedwv]

Yes to deleting the ODM1 code. It's preserved in the pre-alpha branch. The hierarchy is there... I prefer some of a hierarchy. Tired of long files of python code. I'd like models broken up into more functional pieces

[emiliom]

:+1: to deleting the ODM1 code (I assume you've already discussed it with @horsburgh).

The hierarchy is there... I prefer some of a hierarchy. Tired of long files of python code. I'd like models broken up into more functional pieces

I agree that hierarchy is better. But the specific hierarchy we're left with (ODM2) may not have the most useful names and groupings, so it's worth rethinking.

I'm tied up with other things right now (including, by tomorrow, looking at @sreeder's https://github.com/ODM2/ODM2PythonAPI/pull/51). So, as a short-term strategy I think I'd prefer to not change the ODM2 folder for now, and pick up that topic again next week or so.

[emiliom]

Closing. Addressed by PR #81