RADARAPI and DBAPI naming

[rma-rripken]

In 2010 or so a jython object for interacting with the cwms database was created. This class was called DBAPI. People wrote jython scripts that used the interface. Later a Web API for accessing the cwms database was created. This was called RADAR. A new jython class that reimplemented most of the DBAPI methods but against RADAR instead of against raw jdbc connections was created. This class was called RADARAPI because it was like the DBAPI class but communicated with RADAR instead of directly to the DB.
The RADAR service was renamed CDA.
A new name for RADARAPI is needed.

[rma-rripken]

CDAAPI is wrong

[rma-rripken]

Adam suggested:
DBAPI_CDA or CDA_CLIENT

Or renaming DBAPI and RADARAPI into:

cwms_scripting_cda.jy
cwms_scripting_jdbc.jy

[adamkorynta]

if I'm thinking about HEC scripting libraries going forward an hec_scripting_dss.jy would be the next in line for naming.

[rma-rripken]

Daniel voted against anything that includes DBAPI b/c DB API is a python standard ( I think this one https://peps.python.org/pep-0249/ )

[MikeNeilson]

The underscores look wrong to me. How many projects actually name that way in python these days?

[rma-rripken]

Package and Module Names

Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.

When an extension module written in C or C++ has an accompanying Python module that provides a higher level (e.g. more object oriented) interface, the C/C++ module has a leading underscore (e.g. _socket).
Class Names

Class names should normally use the CapWords convention.

The naming convention for functions may be used instead in cases where the interface is documented and used primarily as a callable.

Note that there is a separate convention for builtin names: most builtin names are single words (or two words run together), with the CapWords convention used only for exception names and builtin constants.

[MikeNeilson]

whelp, there it is. and the cwms_scripting_... is about in line with what @krowvin is doing with the Javascript wrapper.

[Enovotny]

what about
cwmsjy for the jython version and
adjust cwmspy to reference CDA for a python 3 version that exports pandas dataframes.

[rma-rripken]

Can you make your suggestion more concrete - I don't want to misinterpret. You are suggesting that DBAPI class is renamed cwmsjy?

[rma-rripken]

I do like having a plan for the future but exporting dataframes would break the current interface and so I think it would be something new and not need to have consistent naming with these classes. Also DBAPI and RADARAPI are jython classes and Jython 3 doesn't exist.

[Enovotny]

yes CWMSjy would replace DBAPI. CWMSpy is a library that already exists for python 3 that exports dataframes. Something that I am going to work on is converting that to use CDA instead of cx_oracle. I was simply suggesting that we make the names consistent between the two.

[willbreitkreutz]

I kind of like that ☝️

[MikeNeilson]

Let's go with cwmsjy and cwmspy. Simple, points out where it's used.

I think our internal Field sufficiently understands the "cannonical" data representation of each (Timeseries Containers for Jython, pandas data frames for python) AND and cwmsr (or maybe Rlang) that creates R data frames would also make sense and be useful in the future and allow similar naming.

Our existing DBAPI can just stay that way, eventually it we be dropped to get everyone though the web APIs