what is the purpose of JDBCoDataServiceList?

[Bartman0]

it seems JDBCoDataServiceList is geared towards the more list-like services as offered by the OData API. but is that differentiation between specific entity set queries and lists of metadata (I presume) not made at the service level and therefore the class that extends JDBCoDataService? I am extending the functionality and I would like to keep in line with your ideas on this, but I am a bit struggling with this to do it correctly.

[wernerdaehn]

I see the confusion.... The goal of this library is to expose one service per schema and table. Imagine a database that has 100'000 tables/views. Wrapping that all into a single oData endpoint with that many different entities would be a nightmare. The only advantage of having one endpoint for multiple tables is to expand them. But frankly, you would rather create a view joining the two and hence this is not a good enough use case to justify the downsides.

Okay, so we have many endpoints, wouldn't it be nice to have one more oData service that lists all oData services? That oData service producing the information is the JDBCoDataServiceList.

[Bartman0]

ah, I am new to OData terminology, and frankly, the rather hefty OASIS/ISO documentation does not make it simple to dive into this stuff. So, I was considering the base URL as being the service, but you intended the /schema/table/RS to be a service, so one per individual table. I did't quite get that, and I therefore could not match it with what I understood from OData. But now I see, I didn't understand why the $metadata for the schema layer and table layer were missing, and how that could work. Clear enough now, every table is it's own service... probably very sane to do in an OData world, I just wasn't at that level yet. Makes stuff also a lot more easy to develop (I think) than one super service OData-style.

Since we are at it: have you ever thought about making the ENTITYSETNAME and ENTITYTYPE more in line with that actual table? in the sense that a Persons table will probably contain Person's, an Orders table will probably contain Order's, etc. The entitytype is now always ROW. and contents of a table is always designated by RS.

FYI I am migrating a Salesforce GRAX solution to a general database solution. and GRAX does list all tables (= entitysets) and all of their attributes at the service root $metadata level. which is a big response, even in simple cases. I was trying to mimic that, but I should be looking at it differently.

[wernerdaehn]

Well, what would be the alternate name to RS and ROW?

/<schema>/<table>/RS could be turned to /<schema>/<table>/<table>, because the RowSet structure is the table structure, hence it should have the same name as the table. Similar argument with the ROW. The structure of one row is the table structure, hence repeating the table name a second time would make sense.

But that would look ugly. Hence I preferred sticking to RS for all RowSets (=JDBC ResultSet) and ROW (=single JDBC row).

And yes, oData is huge but out of those 1000 features users usually just need a few. Finding those few in the entire documentation is though.

[wernerdaehn]

On the topic of one-service-per-table, if all would be one service, the metadata document must dump the entire database data dictionary. All tables with all columns with all settings and relationships. That would be .... huge. Worse, this document is read by clients frequently. Separating the services and light caching of the metadata does streamline the process by a lot.

[Bartman0]

clear, thanks