Build and check a full list of column objects known to PRC

[d-w-moore]

To help with #642 and beyond (check all possible duplication mistakes in the column objects known to PRC's GenQuery1 machinery) we need to

• build a complete list of all columns enumerated by GenQuery DB model classes in irods.models (so irods.models.ModelBase should contain an intermediate list of (numeric_key, column) tuples to preserve information against any potential collapsing from repeated references to any given numeric_key that would result from keeping these in dict form during the DB model classes' compilation phase)
• write a test to check these against rodsGenQuery.h

[trel]

I like it.

Is there a way to produce rodsGenQuery.h automatically in the first place? To reduce the need for a test / confirmation / comparison?

[trel]

Hmm, I guess that doesn't really make any sense. You're comparing the Python against the shipped irods/irods source.

[d-w-moore]

Well ... if there were an API to relay that information to the client, then yes. Otherwise, the best way is probably just copy the header file to this repo and document that this has been done. I don't believe any internals of GenQuery1 will change from now on , though, will they? Unless it would be additions of new columns to the GenQuery1 query machinery? - @korydraughn ?

[d-w-moore]

Hmm, I guess that doesn't really make any sense. You're comparing the Python against the shipped irods/irods source.

Right.

[trel]

yes, ignore me - carry on.

[d-w-moore]

Possibly another way is via a web reference to the source in Github

[trel]

adds a dependency on github to the code/test. open to reasons... but that feels like a vote against.

[d-w-moore]

I'd say we are probably ok, just need to document the test process more fully, with a mention of the dependency on a copy of rodsGenQuery.h in this repo that needs updating whenever its counterpart in https://github.com/irods/irods is updated.

[korydraughn]

Well ... if there were an API to relay that information to the client, then yes. Otherwise, the best way is probably just copy the header file to this repo and document that this has been done. I don't believe any internals of GenQuery1 will change from now on , though, will they? Unless it would be additions of new columns to the GenQuery1 query machinery? - @korydraughn ?

It depends on whether bugs are reported. You are correct that modifications to GenQuery1 are primarily limited to additions of new columns. The internals will be left as is.

I think implementing a small C/C++ tool that prints the mappings defined in rodsGenQueryNames.h would help here. The tool could convert the header to a json file or python file. And anytime we add a new column, we just recompile and run the tool.

[d-w-moore]

I think implementing a small C/C++ tool that prints the mappings defined in rodsGenQueryNames.h would help here. The tool could convert the header to a json file or python file. And anytime we add a new column, we just recompile and run the tool.

While we are reducing labor, does it also make sense to have the tool use a web connection to Github to achieve the copy and translation? Or would we be better to take a path to a local file for that purpose?

[korydraughn]

I was thinking the tool just builds against the locally installed irods-dev package. No need for an internet connection.

[d-w-moore]

I was thinking the tool just builds against the locally installed irods-dev package. No need for an internet connection.

that works!