Gerhard
I'm not following the design of InstantDB or Hypersonic I'm afraid.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 think that aggregate queries (like normal select statements) will be generated code. Maximum speed at run time. BCEL will give us these.
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 we should support all SQL types:Yup, another area wothy of planning. Only supported at the moment are varchar and char.What about datatypes? What datatypes do you want to support?
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...
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.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 a very important is a User Management (like instances and schemas in oracle). Is this a part of the DatabaseManager?
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.
The JDBC spec is designed to be neurtral to a lot of different designs. We can be creative if we want to.
Actions is just the parent of all things that can happen or can be queued to happen.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.
It's key as to why Phoenix exists and could become dominant.
OKAction : 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.
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.
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 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 :)...
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.
Regards,
- Paul H
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
