Thanks, this explanation was very helpful in getting a clearer picture.
I'm still stuck with the rational of an DBDatabase.open() call within this picture. I'm recognizing large parts that deal with database structures, meta data and kind of database implementation independent querying. Also there is support for "data" as result form querying (either related to table/view structure of the database (rows/DBRecord), or even more general aggregated or calculated values). Operating on a real database is covered by several methods / components that all rely on being passed a connection for access. I see the rational for having a driver as a necessary part introducing whatever is needed for the specifics of a given database implementation. But why an open call that takes a connection parameter (that then is not stored)? If (what I have read with the FAQ) this is needed for the driver the it seems more appropriate to me to have it as a call parameter to a driver method or (for being able to pass a driver instance) as a parameter to a driver constructor (if a driver really is supposed to refer to an existing database for being set up properly and such functionality can not be deferred until a true connection is available.) Nevertheless, I just may have missed the rational behind having such an open() method on the DBDatabase class. Rainer On 12.06.2017 22:38, Rainer Döbele wrote: > Empire-db deliberately does never store a connection. > Instead connection and transaction management must be performed on a higher > application level. > > For Web applications e.g. a typical scenario is that a http request marks a > transaction, which consists of a number of database operations. > The whole transaction is then committed if the request as a whole succeeds. > In this case a connection is usually fetched from a connection pool that is > maintained by the application server at the beginning of a request (or when > first needed) and returned to the pool afterwards in order to allow hundreds > of requests to be processed in short period of time. > In that scenario Empire-db cannot know what belongs to a transaction or not > and when it starts or when it ends. > > Typically is it sufficient to create an instance of your database object at > application scope and use it as a singleton. > Multiple threads may now use the database object simultaneously with > different connections and transactions. > Also you can be sure, that Empire-db cannot do anything "hidden" with the > database as only methods that are provided with a connection can actually > perform an operation. > > At application level you might want to handle that differently, depending on > the needs of your app. > > Another concept of Empre-db is that you should make heavy use of subclassing. > In your derived Database class you can store the connection if you wish (good > for single-threaded applications) and overload database functions that > require a connection and supply the one you have stored. > > So in fact, the aim is to provide a tool that does the basics and with > maximum transparency and control rather than having a huge persistence System > (e.g. like JPA, Hibernate) that do all kinds of magic things that you cannot > fully control and that might not suit your needs. > > Regards, > Rainer > > >> from: Rainer Pruy [mailto:[email protected]] >> to: [email protected] >> re: DBReader.open() needs connection? Why? >> >> Hi, >> >> as a novice to empire-db, I just came across the fact that for getting >> "larger" results, you should use a DBReader. >> >> The API doc suggests using "DBReader.open(DBCommandExpr cmd, Connection >> conn)" >> >> However, why would one need to specify a connection when the underlying >> database instance has been opened already >> >> and the DBCommand has been created from that database instance? >> >> While I can see some use cases for executing a query using a different >> connection from the one the database has been opened with, >> >> I would expect the regular case be to open the database instance and then >> execute queries against that opened instance. >> >> >> Do I miss some fundamental aspects of empire-db? >> >> BTW: Is there some additional documentation that illustrates some more >> aspects of the logical design than what is illustrated with the web page >> >> (Empire-db, Empire-db and Struts and Documentation sections)? >> >> >> Regards, >> >> Rainer -- /Rainer Pruy/ Geschäftsführer /Acrys Consult GmbH & Co. KG/ /Theodor-Heuss-Str. 53-63, 61118 Bad Vilbel/ _Tel_: /+49-6101-98760-0/ - _Fax_: /+49-6101-98760-50/ _Web_: /http://www.acrys.com/ - _Email_: /[email protected]/ _Handelsregister_: /Frankfurt am Main, HRA 31151/ _Komplementärin_: /Acrys Verwaltungs GmbH/ /Theodor-Heuss-Str. 53-63, 61118 Bad Vilbel/ _Handelsregister_: /Frankfurt am Main, HRB 57625/
