|
Our other subprotocols seem to be descriptive (e.g., "directory", "classpath", "jar") so I vote for another descriptive name. I think that "memory" is fine.
Bryan raises the issue of how we distinguish the transient in-memory database (implemented by Kristian's patch) from Cheng's implementation, which snapshots the database to disk on exit. Initially, I thought that the subprotocol would be a reasonable place to make this distinction. However, maybe it would be better to distinguish the two behaviors with other attributes on the connection URL. For instance, we could introduce two new attributes: loadFrom=blahblahblah saveOnExit=blahblahblah I like Bryan's 3rd suggestion:
jdbc:derby:in-memory:mydb it says it all, I think. Both transient and non-persistent, are not necessarily accurate, if the feature to save on disk at shutdown is implemented and used (or when using backup), so I prefer "in-memory". Rick wrote:
----- Bryan raises the issue of how we distinguish the transient in-memory database (implemented by Kristian's patch) from Cheng's implementation, which snapshots the database to disk on exit. ----- To clarify, I'm hoping to incorporate Cheng's features into the Derby code line, possibly with help from Cheng himself. Note that the database won't be saved to disk on exit by default, you have to set a property to do that (I think in Cheng's patch it was a system property). Regardless of whether such a feature is added or not, the database must be considered transient. A crash or abnormal VM shutdown will cause [all] data to be lost. Also note that even without the specific feature mentioned, the user can explicitly "snapshot" the database by invoking Derby's existing backup routine(s), and then restore the database on boot/creation (for instance by using the createFrom URL attribute). The difference between the save on exit feature and the backup mechanism, is that the former is automatic on shutdown. I don't think the existing backup routines can be easily invoked from the in-memory storage engine. Thanks for the comments so far, and keep'em coming ;) My vote goes to "memory" because
1) It's sufficiently easy to type (short and no special characters) 2) It's consistent with the other sub-protocols (they're not named "in-jar" or "in-classpath") 3) It's sufficiently descriptive (I feel that the proper place to describe this feature is in the documentation, not in the URL ;) But I'm fine with any of the alternatives suggested so far. +1 for 'memory'. To me it is descriptive enough and it says that if I have had writes to this database, I will loose them in case of a crash.
Note that other RDBMS supporting the in-memory mention in the JDBC connection URL such as h2 or hsqldb uses 'mem'. Patch 1a changes the subSubProtocol name to 'memory'.
A typical connection JDBC URL (for the embedded driver) will then be 'jdbc:derby:memory:wombatDb'. Committed patch 1a to trunk with revision 753195.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Closed
Major
means that my data is completely transient and will be wholly discarded when the
database is shut down, then I'd be in favor of a URL which makes that rather explicit:
jdbc:derby:transient:mydb
jdbc:derby:memory-only:mydb
jdbc:derby:in-memory:mydb
jdbc:derby:non-persistent:mydb