The connection param on database open method is intended to give both the database and the database driver the chance to do perform initialization tasks if required.
Some drivers (like e.g. SQL-Server database driver) have an option for using a Sequence table. The driver then make sure the Sequence table exists and crates it if not. Also I think the Postgre-SQL driver uses this to make sure a particular stored procedure exists. Personally I use this in my database implementation to load some database related configurations stored in the database. If you are sure you don't need it there, just pass null for the connection parameter. And if you think it's a good idea to store it with the database in your scenario then you might as well override the method and do it there. Hope this helps. Rainer from: Rainer Pruy [mailto:[email protected]] to: [email protected]; Rainer Döbele <[email protected]> re: Re: DBReader.open() needs connection? Why? 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: mailto:[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: mailto:[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
