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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
