RE: Discussion Topic #2 Databases

Thanks Hal. 

We did not know about that DB and it is LGPL.

http://www.daffodildb.com/onedollardb-opensource.html



Julio

> -----Original Message-----
> From: smartfrog-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:smartfrog-
> developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Hal Hildebrand
> Sent: 19 January 2006 15:53
> To: Steve Loughran; smartfrog-developer
> Subject: RE: [Smartfrog-developer] Discussion Topic #2 Databases
> 
> You might want to check out One$DB - aka daffodil.  This is a full
> featured, pure Java DB that's also pure JDBC.  Probably one of the
nicest
> things in open source I've seen in quite a while (besides SmartFrog,
of
> course).
> 
> -----Original Message-----
> From: smartfrog-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:smartfrog-
> developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Steve Loughran
> Sent: Thursday, January 19, 2006 7:23 AM
> To: smartfrog-developer
> Subject: [Smartfrog-developer] Discussion Topic #2 Databases
> 
> 
> Hello,
> 
> This is just a note to start some discussion on the mailing list as to
> what people out there think SmartFrog needs in terms of database
support
> in the next year.
> 
> -We have a MySQL component from the seed project that we are thinking
of
> moving in to the SourceForge repository; I don't know what
> tests/documentation it has. Are there any interested users who could
> help with those?
> 
> -for demos and testing, HSQLDB is probably adequate, as it is the
> simplest of the pure-java datastores. It could have a component to
> configure it without too much effort.
> 
> -I haven't looked at Apache Derby at all.
> 
> I don't want to try and define generic database deployment components,
> because it only creates the illusion that you can switch database
> engines on the fly, which everyone knows is even less sensible than
> switching app servers between installations. But we might benefit from
> having some components whose aim in life is to create and issue SQL
> commands against JDBC bindings
> 
> It would have the following (probably syntactically incorrect)
components
> 
> -JdbcBinding to declare a JDBC binding
> -SqlTransaction for a SQL XA.
> -SqlLiveness to issue a select against a DB for liveness, failing with
> an error  or if the result count is more/less than expected, maybe
even
> a different value
> 
> -SqlDeployment to issue different commands/XAs when
> deploying/undeploying something. So at deploy time you could create a
> table, and at undeploy time it could be dropped.
> 
> The JDBC binding would look like this
> 
> mysql extends JdbcBinding {
>    classpath "optional-extra-jars";
>    classname "com.mysql.JdbcDriver";
>    url TBD;
>    user TBD;
>    password TBD;
> 
>    options  [["name","value"],["name2","value2"]];
> }
> 
> With a sql transaction a very thin wrapper around the java.sql API:
> 
> insert extends SqlTransaction {
> 
> 	id TBD;
> 	date TBD;
> 	text "";
> 
> 	command "insert into table events values(?,?,?);"
> 	arguments [id,date,text];
> 
> }
> 
> doInsert extends insert {
> 	db LAZY mysql;
> 	id "f324";
>   	date "2006-01-19;
> 	text "test";
> }
> 
> A component to have both deploy and undeploy commands would just be an
> extension, taking two
> SqlDeployment  extends Prim {
> 	db TBD;
> 	deploy extends SqlTransaction {  .. }
> 
> 	undeploy extends SqlTransaction {  .. }
> }
> 
> The only complication there is that I would not want the nested
> transactions to bind to anything other than the outer jdbc binding,
> which is going to be fiddly to make implicit.
> 
> The liveness would just be a way of defining the health of a database
if
> a select operation succeeds with the # of values returned in the
> expected range, possibly with a list of values that get checked too.
> That would appear to be the simplest way to do database health checks.
> 
> Comments?
> 
> -Steve
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Smartfrog-developer mailing list
> Smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/smartfrog-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
> _______________________________________________
> Smartfrog-developer mailing list
> Smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/smartfrog-developer


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642