And that's life how it should be :) I'm even going to use EmpireDB for some Big Data Spark SQL soonish. Will contribute driver if any of the defaults aren't sufficient!
Cheers, Daniel Sent from my iPhone > On Jun 12, 2017, at 4:38 PM, Rainer Döbele <[email protected]> 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 >
