How addresses OERA the "anywhere"-paradigm for the database platform? I remember the powerpoints of the 90'ies with "any", "any", "any", but I don't see anything special for supporting DataServers.
What is it that you are expecting to see? A dataserver is just another form of managed data source.
In fact, with a Sonic Data Server, it could even be Oracle without a data server connection.
What is it that you are expecting to see? A
dataserver is just another form of managed data
source.
In fact, with a Sonic Data Server, it could even be
Oracle without a data server connection.
For DataServers you can provide SQL-hints in the ABL. How are you going to support multiple database types with a single data access component? Or is the idea to create a data access component per database type (I don't think so).
There are some subtle differences in transaction handling and isolation for the supported database types. And Oracle has no word-index for instance. Sometimes it can be more convenient to put in a stored procedure call in the ABL (yes you can instead of using ABL database access. I wonder where you're going to put this stuff and how well your business logic will be isolated from the database type. Has this been tested with AutoEdge for instance?
The DAO is exactly the right place for handling data source specific issues - this includes if the data source is a flat file, a Web Service, a Sonic source, an OpenEdge Database or of course a DataServer Database. Whether you want to have a separate DAO for each of these different data sources or merge them into one might depend on what you are trying to achieve and how different the supported data source types are.
Personally, I find it unlikely that in a single instance of an application any given BE will use 2 different data source types. That said for a given application, Site 1 might use an OpenEdge DB, Site 2 Oracle DataServer and then HQ needs to get data from 2 different data source types. In such a configuration though, you might have bigger issues regarding how to combine the data from the 2 different data sources, etc.
The DAO is responsible for mapping the logical to the physical. All business logic should be in the BE. Only data source specific things should be coded in the DAO. One example of database specific things might be SQL-hints; another might be calling stored procedues (only for database specific logic/updates - no business logic); another might be the XML namespace used; etc.
As far as I'm aware, there was no work put into DataServer specific implementations of the DAO's for AutoEdge, but if anyone has something to share, I'm sure we'll find people here to review it
Jaime has already given the answer I would have given, but let me extend it a little more. Yes, the data access component is the perfect place to customize according to the data source. As noted, this might be a unified component or it might be different flavors according to the database to be used. One of the conspicuous examples of this in a distributed environment is that in some cases a particular entity will come from a local source and in others it will result in a request over the wire for the data from a remote source. These components will have the same signature so they can be used interchangably by the rest of the application and one will simply deploy one or the other according to the configuation.