One of our database does only have an "old" odbc connector. A coworker asked me to develop a web-service that will fetch database records into a json array (client is not an "Delphi" application) :
I'm using "employee" table in this example, but it should be any table from my ODBC connection. Data will only be fetched (GET), so no insert / delete nor update here.
it is not clear to me how this differs from regular XData behavior? That's what XData does, at first sight. What exactly is peculiar in this situation that makes you wonder if it's possible to do with XData?
I want to know if there is a way to make the "resource path" dynamic ?
In all documentation examples, an entity need to be created.
My database is only accessible via an ODBC link and does contains a lot a tables. I don't want to create each entity for each table... thus my question. I'm wanting xdata to behave like an bridge between my table and my web clients.
Since XData uses Aurelius under the hood, every resource needs a class indeed to be mapped, so it's not possible (or very difficult) to make it dynamic. Yes, Data Modeler makes that process very very easy, actually in a few minutes you can have your tables published through a XData server the way you want, but indeed you need to create those classes using Data Modeler and recreate them if the underlying database changes.
What database type you want to access? Data Modeler needs to know the database in order to build the proper SQL syntax to retrieve the database structure. Then does this database is only access by ODBC driver?
I need to connect to a 4D (4th Dimension) Database. A crappy database engine that need an ODBC driver. It's SQL dialect is either "OpenSQL" or 'msAccess" compatible.
One of our linux server needs data from this 4D database and there is no JDBC connector available. Restfull API is a viable option.
I understand. Well, in this case, as I said, the problem is not even the ODBC or JDBC, but the SQL syntax. You might have basic things working with XData if SQL is compatible enough, but without proper and specific support from our side, you will end up with things not working here and there - like some types of expressions, filtering, or even blob handling.
Believe me, each database server and each component access has its own issues, bugs, behaviors. If you have watched the video "Maturity" of the Aurelius top 10 features you will see that I really meant it there. We really have to test all combinations because they are not consistent at all. It's us that need to make it consistent, so XData (and Aurelius) will only reliably work 100% with 4D Database if we really test and implement (if needed) all its specifics and workarounds.
But well, if you want to try and do an experiment anyway, you could try to somehow convert such database to SQL Server (or maybe Access and export to SQL Server) just to extract the database structure and generate the Aurelius classes more or less compatible with structure, and see how far XData goes with it, using ADO (for ODBC connection). As I said, probably the basic stuff like the CRUD statements without much fancy stuff will work.