avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: [AvalonDB] some thoughts
Date Tue, 30 Oct 2001 22:39:10 GMT
Hi,
>Gerhard,
>
>>Hi,
>>I took a look at the structure of the AvalonDB and
>>have some questions and proposals (I know that the
>>structure is in a developing state. So please don't
>>feel assaulted!!)
>>
>No problem dude.  Say anything you like, I am only motivated by 
>perfection not (false) pride.
same as I...
>
>>I attached 2 new Actions and Requests. Alter and Grant.
>>Because they are very common SQL Satements for Database
>>Administration (please correct me, if I'm wrong!).
>>
>I've committed them as is.
Thanx.
>
>>Also I think some interfaces are missing, like Trigger,
>>Cursor,Constraint and Key. My first thought was to put them
>>in the data package, but I'm not sure.
>>
>Yes they are interesting and worthy of thought.
>
>>Further I miss something like functions. The guys from hsqldb 
>>put them all in one Library class. 
>>
>Yup that is missing too for the moment.
I don't know. The guys from hsqldb put them all in one class.
But this is not very java. The people from simpleDB have
for each function a own class. I like this way more. But functions
are closly linked together with actions somehow
(SELECT SUM(salary) FROM employee). Maybe we have to combine them,
when we create actions.
>
>>What about datatypes? What datatypes do you want to support?
>>
>Yup, another area wothy of planning.  Only supported at the moment are 
>varchar and char.
I think we should support all SQL types:
CHAR,VARCHAR,LONGVARCHAR,NUMERIC,DECIMAL,BIT,TINYINT,SMALLINT,INTEGER,  
BIGINT,REAL,FLOAT,DOUBLE,BINARY,VARBINARY,LONGVARBINARY,DATE,TIME,TIMESTAMP
That's is easy to say, but...
>
>>I think a very important is a User Management (like instances
>>and schemas in oracle). Is this a part of the DatabaseManager?
>>
>I think the Oracle design is imperfect.  Users get a default schema (or 
>vice versa), but rights can be granted to escape that constraint.  I 
>need to read up on "catalog" that JDBC recognises.  My main SQL 
>experience is from DB2 where "collection" is the name given the 
>directory concept that could contain tables etc.  They are all in the 
>end variations of "path", but I think we should stay close to a JDBC 
>design and hopefully clean in idea at that.
>
I think I have to read up on this, too. Do you have some internet resources
about that point? I didn't found something about that in the JDBC specification
of javasoft. But maybe I was blinded.
>>Last but not least some questions about the package structure:
>>I don't really understand the difference between Action and 
>>WriterAction? Also I don't really comprehend the existence of
>>the transport and the service package, what do they capsulate?
>>Can sombody enlighten me a little bit :))
>>
>Service is the key Avalon/Phoenix concept.  Different server designs can 
>be tied togther with XML.  Many implementations of the same thing should 
>yield a highly configurable server.  Started today were two 
>implementations of persistence.  One uses Cornerstone's store and 
>serialization (flawed for a large system).  The other is a "no 
>persistence" in memory model.  I.e. the server crashes or is stopped and 
>the data is binned.  Also services can be used by other server 
>applications *inside* the same JVM.  Take a look at 
>http://jakarta.apache.org/avalon/phoenix/
Ok I will do my homework.
>
>Action : I think of a sequence of things that could happen to tables as 
>part of a transaction or not.  They are strong Java objects that have an 
>execute() method.  They are the result of parsed and processed SQL and 
>can be cached for future use.  
Yeap
>
>The Command structure (incomplete like most things) in the transport 
>package allows multiple designs for transport of request and resulting 
>replies.  I have a simple (slow) CommandStream at the moment that should 
>work fine.  In time we can (using Phoenix's pluggable design) retrofit 
>other transports.  RMI, bytestreams (like hypersonic) and SOAP could be 
>alternate transport mechanisms.
Sounds very cool. 
>
>I think we may end up with jars like so :
>
>  avalon-db-client-rmi.jar
>  avalon-db-client-bytestream.jar
>  avalon-db-client-cmdstream.jar
>  avalon-db-client-soap.jar
>
>Anyway, welcome aboard dude.  Take a look at my latest changes that use 
>BCEL for dynamic bytecode generation for table creation.  This will 
>really come into its own when select statements are processed.
Thanx for hospitality :).
Can do me a favour. Please explain me in few words the flow of the SQL
execution from the CommandConnector to the BCELSQLParser in the current
structure. I have a flow in mind, but I don't kow if I'm right.

Ok BCEL, I didn't find much about that project on the jakarta sides.
But when inpret the code right, your aproach is to dump tables as java
classes down to the filesystem. I hope that's not totaly wrong.

Ok, what are the next steps :)...

Cheers
Gerhard

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message