You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Gerhard Froehlich <g-...@gmx.de> on 2001/10/30 18:20:35 UTC
[AvalonDB] some thoughts
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!!)
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!).
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.
Further I miss something like functions. The guys from hsqldb
put them all in one Library class.
What about datatypes? What datatypes do you want to support?
I think a very important is a User Management (like instances
and schemas in oracle). Is this a part of the DatabaseManager?
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 :))
Cheers
Gerhard
Re: [AvalonDB] some thoughts
Posted by Paul Hammant <Pa...@yahoo.com>.
Kasper,
>Im not sure of what actions exactly do (in Avalon), but have you thought of
>using javacc for parsing?
>
Actions are not an avalon concept. They are part of AvalonDB only.
They are just parsed/processed SQL requests. The current impl will use
BCEL for strongly typed actions.
JavaCC ? Yup, I thought of that, but figured we could switch over at
some later point. I've not done any before. I note that your exellent
BCEL project has a "mini" parser built in. It uses JavaCC and look
quite interesting. More things for me to learn ;-)
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AvalonDB] some thoughts
Posted by Kasper Nielsen <ne...@kav.dk>.
btw.
check out http://mckoi.com/ (another open source Java DB project) they use
javacc to parse expressions.
- Kasper
----- Original Message -----
From: "Kasper Nielsen" <ne...@kav.dk>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Wednesday, October 31, 2001 11:31 AM
Subject: Re: [AvalonDB] some thoughts
>
> ----- Original Message -----
> From: "Paul Hammant" <Pa...@yahoo.com>
> To: "Avalon Developers List" <av...@jakarta.apache.org>
> Sent: Tuesday, October 30, 2001 9:02 PM
> Subject: Re: [AvalonDB] some thoughts
>
>
> > 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.
>
> Im not sure of what actions exactly do (in Avalon), but have you thought
of
> using javacc for parsing?
>
> - Kasper
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AvalonDB] some thoughts
Posted by Kasper Nielsen <ne...@kav.dk>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Tuesday, October 30, 2001 9:02 PM
Subject: Re: [AvalonDB] some thoughts
> 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.
Im not sure of what actions exactly do (in Avalon), but have you thought of
using javacc for parsing?
- Kasper
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AvalonDB] some thoughts
Posted by Paul Hammant <Pa...@yahoo.com>.
Gerhard,
>>What thought?
>>
>I agree, you're the boss.
>
No bosses dude!
>For me it is always important to have a little
>"roadmap" in mind. Know everything is fine :).
>
Cool then, we'll morph the roadmap as we go along.
>>Lastly, Gerhard - your email address is bouncing things back to me
>>undelivered ... :-(
>>
>F*** GMX. I don't know, sometimes I have problems with my email account. Maybe
>I should switch to my yahoo account for contributing over this mailing lists.
>But why is it bouncing?? This mails are pure text and no html (I'm using Outlook
>2000).
>
It's more the server at you end, than the client. I'll try again.
>FYI. Meanwhile I'm completing the JDBC Driver with
>java.sql.DatabaseMetaData
>java.sql.ResultSetMetaData
>According to the JDBC specification this interfaces must always be fully
>implemented.
>http://java.sun.com/products/jdbc/driverdevs.html
>
OK watch out, I renamed all the ApacheDB objects to AvalonDB a couple of
hours ago, including ApacheDBResultSet.java and ApacheDBDatabaseMetaData.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [AvalonDB] some thoughts
Posted by Gerhard Froehlich <g-...@gmx.de>.
Paul,
>Gerhard,
>
>>Maybe first of all, before starting wild coding, we should limitate the
>>functionalities of this DB server.
>>What should he be able to do and what not:
>>Datatypes?
>>Functions?
>>Any other DB objects like triggers,indexes?
>>
>>Maybe we should take, according to Ulrich the SQL92 Standard as core
>>functionality first.
>>
>>But I would keep the other functionalities in mind, you never know.
>>
>I kinda hope that we do it all in the end.
>
>The plan (in defence of "wild coding")....
>
>1) get to the stage where CREATE TABLE, INSERT and SELECT (simple) work
>over JDBC. This includes the first indexes (see
>http://www.coyotegulch.com/jisp/index.html )
>2) refactor based on what learned (we're not supporting a userbase so
>this is quite easy to do).
>3) Add remaining basic operations (UPDATE DELETE etc).
>4) Add functions, triggers, aggregate concepts.
>5) Work on other forms of persistence, transport (this is phoenix level
>multiple implementation of services).
>
>What thought?
I agree, you're the boss. For me it is always important to have a little
"roadmap" in mind. Know everything is fine :).
>
>Lastly, Gerhard - your email address is bouncing things back to me
>undelivered ... :-(
F*** GMX. I don't know, sometimes I have problems with my email account. Maybe
I should switch to my yahoo account for contributing over this mailing lists.
But why is it bouncing?? This mails are pure text and no html (I'm using Outlook
2000).
FYI. Meanwhile I'm completing the JDBC Driver with
java.sql.DatabaseMetaData
java.sql.ResultSetMetaData
According to the JDBC specification this interfaces must always be fully
implemented.
http://java.sun.com/products/jdbc/driverdevs.html
Cheers
Gerhard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AvalonDB] some thoughts
Posted by Paul Hammant <Pa...@yahoo.com>.
Gerhard,
>Maybe first of all, before starting wild coding, we should limitate the
>functionalities of this DB server.
>What should he be able to do and what not:
>Datatypes?
>Functions?
>Any other DB objects like triggers,indexes?
>
>Maybe we should take, according to Ulrich the SQL92 Standard as core
>functionality first.
>
>But I would keep the other functionalities in mind, you never know.
>
I kinda hope that we do it all in the end.
The plan (in defence of "wild coding")....
1) get to the stage where CREATE TABLE, INSERT and SELECT (simple) work
over JDBC. This includes the first indexes (see
http://www.coyotegulch.com/jisp/index.html )
2) refactor based on what learned (we're not supporting a userbase so
this is quite easy to do).
3) Add remaining basic operations (UPDATE DELETE etc).
4) Add functions, triggers, aggregate concepts.
5) Work on other forms of persistence, transport (this is phoenix level
multiple implementation of services).
What thought?
Lastly, Gerhard - your email address is bouncing things back to me
undelivered ... :-(
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [AvalonDB] some thoughts
Posted by Gerhard Froehlich <g-...@gmx.de>.
>Paul Hammant wrote:
>>
>> Ulrich,
>>
>> >FYI, the SQL-92 datatypes are:
>> >
>> >INTEGER, SMALLINT, NUMERIC, DECIMAL
>> >REAL, DOUBLE, FLOAT
>> >CHAR, VARCHAR
>> >BIT
>> >DATE, TIME, TIMESTAMP, INTERVAL
>> >
>> >All the other types you mentioned are PROPRIETARY, don't waste your time
>> >implementing proprietary Oracle or Sybase constructs. Additionally I
>> >think supporting VARCHAR would be enough at first, the other datatypes
>> >can be derived from it.
>> >
>> That's probably good advice. The mappings between those and normal Java
>> objects are mostly quite good.
>
>Also, consider that things like stored procedures, triggers, user
>management, indexes are not part of any standard, they are also
>proprietary concepts and solved differently in every database server.
Maybe first of all, before starting wild coding, we should limitate the
functionalities of this DB server.
What should he be able to do and what not:
Datatypes?
Functions?
Any other DB objects like triggers,indexes?
Maybe we should take, according to Ulrich the SQL92 Standard as core
functionality first.
But I would keep the other functionalities in mind, you never know.
Cheers
Gerhard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AvalonDB] some thoughts
Posted by Ulrich Mayring <ul...@denic.de>.
Paul Hammant wrote:
>
> Ulrich,
>
> >FYI, the SQL-92 datatypes are:
> >
> >INTEGER, SMALLINT, NUMERIC, DECIMAL
> >REAL, DOUBLE, FLOAT
> >CHAR, VARCHAR
> >BIT
> >DATE, TIME, TIMESTAMP, INTERVAL
> >
> >All the other types you mentioned are PROPRIETARY, don't waste your time
> >implementing proprietary Oracle or Sybase constructs. Additionally I
> >think supporting VARCHAR would be enough at first, the other datatypes
> >can be derived from it.
> >
> That's probably good advice. The mappings between those and normal Java
> objects are mostly quite good.
Also, consider that things like stored procedures, triggers, user
management, indexes are not part of any standard, they are also
proprietary concepts and solved differently in every database server.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AvalonDB] some thoughts
Posted by Paul Hammant <Pa...@yahoo.com>.
Ulrich,
>FYI, the SQL-92 datatypes are:
>
>INTEGER, SMALLINT, NUMERIC, DECIMAL
>REAL, DOUBLE, FLOAT
>CHAR, VARCHAR
>BIT
>DATE, TIME, TIMESTAMP, INTERVAL
>
>All the other types you mentioned are PROPRIETARY, don't waste your time
>implementing proprietary Oracle or Sybase constructs. Additionally I
>think supporting VARCHAR would be enough at first, the other datatypes
>can be derived from it.
>
That's probably good advice. The mappings between those and normal Java
objects are mostly quite good.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AvalonDB] some thoughts
Posted by Ulrich Mayring <ul...@denic.de>.
Gerhard Froehlich wrote:
>
> 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...
FYI, the SQL-92 datatypes are:
INTEGER, SMALLINT, NUMERIC, DECIMAL
REAL, DOUBLE, FLOAT
CHAR, VARCHAR
BIT
DATE, TIME, TIMESTAMP, INTERVAL
All the other types you mentioned are PROPRIETARY, don't waste your time
implementing proprietary Oracle or Sybase constructs. Additionally I
think supporting VARCHAR would be enough at first, the other datatypes
can be derived from it.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AvalonDB] some thoughts
Posted by Paul Hammant <Pa...@yahoo.com>.
Gerhard
>>>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:
>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...
>
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
>>http://jakarta.apache.org/avalon/phoenix/
>>
>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.
>>
>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
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.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [AvalonDB] some thoughts
Posted by Gerhard Froehlich <g-...@gmx.de>.
>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.
Ehh, I found it in the cvs repository. First think then write :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [AvalonDB] some thoughts
Posted by Gerhard Froehlich <g-...@gmx.de>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AvalonDB] some thoughts
Posted by Paul Hammant <Pa...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>