Re: [AvalonDB] some thoughts

[Paul Hammant]

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.

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.
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.
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 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.

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/

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.  

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.  

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.

Regards,
- Paul H

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>