avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: [AvalonDB] some thoughts
Date Tue, 30 Oct 2001 23:53:23 GMT

>>>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.
I'm not following the design of InstantDB or Hypersonic I'm afraid.
I think that aggregate queries (like normal select statements) will be 
generated code.  Maximum speed at run time.  BCEL will give us these.

>>>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:
>That's is easy to say, but...
Fine.  As it happens there is no architecture yet for types.  We need a 
decent factory concept for mappings of sql types to Java types.

>>>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.
SQL is the most unwritten about major technology that there is.  My ten 
years of it is based mostly on DB2/400 with a more recently Oracle8i, 
Sybase and Hypersonic.

The JDBC spec is designed to be neurtral to a lot of different designs. 
 We can be creative if we want to.

>>>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 :))
Actions is just the parent of all things that can happen or can be 
queued to happen.

>>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 
>Ok I will do my homework.
It's key as to why Phoenix exists and could become dominant.

>>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.
>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.
1) the client loads and uses the JDBCDriver.
2) In that client VM, a Socket is opened on the server and one of a 
number of commands is streamed to it.
3) On the server the command is retrieved from the stream (multiple 
threads handled by Cornerstone)
4) The request may be optimized (making another request)
5) The request is parsed, and in the current implementation, BCEL 
generates java bytecode that fits the action architecture.
6) Caching of actions will happen here one day
7) The action is executed and a reply is streamed back to the client 
containing an appropriate repsose.
8) The JDBC driver takes the reply an re-represents it as pure JDBC things.

>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.
The filesystem dump has stopped now.  I found it necessary to use "jad" 
to decompile the class to see if I was doing the right thing.

>Ok, what are the next steps :)...
Find anything you like dude.

I have not finsihed the Request/Reply trees of classes.  Also in the 
JDBC driver, PreparedStatement & CallableStatement are not done yet.  Go 
through the JDBC code (if you want) looking for use of debug() ( an 
indication of "TODO" ).

Basically anything you like.


- Paul H

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

View raw message