Comments (5)
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
.
from jdbcodata.
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.
from jdbcodata.
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.
from jdbcodata.
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.
from jdbcodata.
clear, thanks
from jdbcodata.
Related Issues (5)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jdbcodata.