Sorry to be so long answering. Design questions always make me think...
This is a good idea. There are actually two variations:
1) As Emmanuel suggests, we can assign a timestamp based on the
document. XML-DBMS would return this to the application as separate
metadata when the application retrieves the document. The application
would return this to XML-DBMS when updating the document. To identify
individual documents, it would probably be sufficient for the
application to pass in the (pre-update) key value(s) and root table(s)
(a DocInfo object?). Note that the pre-update values would have to be
used since these could have changed -- the obvious case is a document
with an ignored root in which elements at the next level down are added
or deleted.
2) We can use timestamp/value columns in the database. These would be
identified in the map and would form the basis for optimistic locking
comparisons. For example:
<!ELEMENT ToClassTable (Table, (TimestampColumn | ValueColumn+)?)>
<!ELEMENT TimestampColumn EMPTY>
<!ATTLIST TimestampColumn
Name CDATA #REQUIRED
Generate "Yes | No" #REQUIRED>
<!ELEMENT ValueColumn EMPTY>
<!ATTLIST ValueColumn
Name CDATA #REQUIRED>
Note that the timestamp/value column(s) would need to be mapped
separately to the XML document. That is, they would be included in the
XML document as data, not metadata.
The first option is relatively simple, but has the disadvantage that it
only works if the data is not updated through another document or
through a separate (non-XML-DBMS) application. The second option
provides a more complete solution, but has the disadvantage that
timestamp information is included in the document, which may be
confusing to some users.
-- Ron
Emmanuel Clarke wrote:
>
> --- In xml-dbms@egroups.com, Ronald Bourret <rpbourret@r...> wrote:
> > 3.3) Optimistic Locking
> > -----------------------
> > A problem with optimistic locking just occurred to me. This that
> > XML-DBMS does not keep an original copy of a document. Therefore,
> when
> > it receives a document for update, it has nothing to compare against
> > what is in the database to determine if somebody else has changed
> the
> > document in the mean time. That is, if a user makes a change, XML-
> DBMS
> > won't be able to tell if the difference between the document and the
> > database is due to the user's change or to somebody else changing
> the
> > database.
> >
> > The only workaround I can think of is a retrieveForUpdate method,
> where
> > XML-DBMS keeps a copy of the document. The obvious problem with
> this is
> > that people could check out large numbers of documents and easily
> > overwhelm memory.
> >
> > Suggestions welcome.
> >
>
> How about adding metadata for each document (or element?) which would
> contain a timestamp indicating the last modification date/time.
>
> You would somehow have to uniquely identify the document/element in
> order to retrieve its metadata, but this is something that needs to
> be done anyway.
>
> There are obvious disadvantages when you get into fine grained
> updating of elements within a document that may be shared with other
> documents, but it may be a viable approach when you only want to deal
> with a single document.
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
I've added this to the 2.0 spec, which is now available online at:
http://www.rpbourret.com/xmldbms/specs/index.htm
I'll try to update the spec as ideas move from the purely speculative
stage to the somewhat concrete stage.
-- Ron
"Khan, Terrick" wrote:
>
> It would be nice to get support for ID/IDREF attributes :)
Dear All,
I have been looking @ how other dbms interactive systems handle Updates
(e.g. EJB CMP systems).
I reckon that the timestamp added by the dbms on Insert & then amended on
insert is going to be the best way. However a thought has occurred.
If one could assume that an XML "message" (i.e. a doc sent to the dbms for
inclusion in the dataset) with a Pri_key is an update whereas where the
pri_key field is null is an insert........then surely one could also assume
that any document without a timestamp is either an insert or is read-only.
i.e. Prikey but no ts = readonly
No Pri_key = insert (whether with or w/o a TS)
Pri_Key + TS = update.
BTW I've also been looking @ the schema docs now that schema's are getting
to be nearly adopted. It seems obvious to me that they are heavily aimed at
representing database based records.
Should we aim to move wholeheartedly to Schema's for version 2? The
advantages seem (to me) to be so clear over DTD's (e.g. type checking & the
handling of "complex types").
BTW BTW I've also also been looking @ a very interesting thing called
"schematron" which allows for the application of logic on the xml doc
itself. Application of choice logic to XSLT in effect.
Adam
Dear Ronald,
2) Map Objects:
2.1) Hooray.
2.2) Hooray again
2.3) Good idea. Would allow the Connection pool methods to be hardened (i.e.
lots of optimization could occur which in no way alter anything else
(retries,2 stage commits etc.))
2.4) My main thought is why DTD instead of Schema's? If you could get the
typing (as an example) of a given element via the DB metadata then why not
persist such information? It should be reasonably easy to map SQL/JDBC
typing to the XML metadata.
2.5) I think it is a good idea as well.
2.6) Yup.
2.7) Good
2.8) If the XML metadata was to be done as Schema's then XML schema
generation should be ***reasonably*** simple. I reckon that now schema's are
headed towards "going gold" then people will move wholesale to schema's
simply becuase of the advantages derived at the client end (e.g. casting a
string to a date & then showing it / updating it via a GUI DateBean) & at
the "middleware" part (e.g. checking that values are legitimate before
throwing the doc @ a DB & being told of illegitimate strings (e.g. string in
a Int column)).
2.9) This will have to be designed to be modular such that particular
foibles of particular DB'es can be compensated for. IMHO if this is
carefully designed then it could be used within the DB > MAP generation as
most/all serious DB'es have structures
(e.g. the SYS tables) which allow for querying in order to find loads of
info for easy building (e.g. Pri_key column for a given table, view or a
table (i.e updatable, not updatable ), foreign key relationships etc. i.e if
you were to ID the DB as say Oracle 8.0 or DB2 V7.1 then the SQLDB > MAP/
Schema builder could use class'es / JDBC Queries to find PK & FK info etc. I
could happily build something like that (& have been looking @ doing so) for
DB2 but so long as the interfaces were clearly built (e.g. getForiegn_keys()
where the arg is a table name (fully qualified)
2.10) This comes down to simply whether DTD's will persist in use or whether
(as indicated above) schema useage is the norm/base level. If schema's were
to be the base level of XML structuring then this is covered within the
Schema spec.
2.11) First off we have to work out what all the options are /will be (@
least for v.2). Again if the base structure was schema's then I reckon
they'd be best held in the schema (one place to check, easier build &
deploy).
3)
3.1) YES!!!! IMHO housing XML-DBMS on the client is simply as mistake (e.g.
updating problems multiple copies of what only needs to be held once @ the
center etc.etc.
My idea is along the lines of building clients which have NO JDBC in them @
all. JMS OK, RPC/EJB/CORBA OK. i.e the system works @ a ****Document
level**** & the clients are built to deal with documents. I reckon XML-DBMS
should be capable of being housed in 3 places (all server-side) (1) As a
sored proceedure in a DBMS trigger (insert of update) (2) As a standalone
server process (3) Within an EJB Container.
3.2 & 3.3) (a) @ a simple level (& in terms of efficiency (in case of
scaling)) the timestamp option is the best. The "values" scenario has me
interested in terms of client side classes (see "Client Side Classes"). One
point which is that rather like having the Pri_key for every table
referenced, you would need the TS for every table reff'ed OR check against
the produced document (assuming a new one is produced following every
update). Another quick question (probably leading to a loooong answer) is
Can the update/insert statement be constructed so as to only update / insert
on the fields/columns which require it? If so then the values approach
becomes much stronger.
3.4) OK
4)
4.1) If the parser & the JDBC Info can be abstracted / loaded from external
sources then I will start on the transfer GUI initially.
4.2)OK
4.3)Here I have a number of points / pointlets
a) Password should be there even if the GUI never writes it (i.e. it could
be included by hand editing the properties file. The main reason for this
would be for use in pure serverside stuff (e.g. running XML-DBMS as a stored
procedure called from within a trigger in the dbms).
b) I have done this for JDBC access for db'es running from Oracle thorough
Db2 to Access. the url part is different but users will just have to look
that up (much like they'd have to look up what the DB name was & what port
the JDBC handler might be running on (if using lightweight / net JDBC
drivers)). Simply put the things like user name/ password are ignored where
not required (e.g. Access). This is no big thing however it does lead to
something which needs thought.
c) Logon in general.
It strikes me (for a number of reasons) that we should construct XML-DBMS
such that it can be called with all the external settings (esp the UserID &
Password). i.e. It is common in "audited systems" to (a) record the last
update / insert timestamp (needed anyway by us for update) & (b) to record
the User who made the change. This last bit is often vital in terms of
finding the record you just inserted e.g. you have a table with fields
Pri_Key,text,UserID,LastChange_TS. You insert into that table. How do you
then find which record you just inserted (e.g. for inserting child elements
into child tables & setting the foreign key )? Assuming Pri_Key is some form
of autoincrementing field (or you could use the timestamp) you then simply
have to call "select max(Pri_key) from table where userid =". Implementing
this should be easy enough as you simply use the same logon box as with the
GUI tools such that hitting "OK" calls a verification select just to test
that the db is @ that URL, the driver can be found & loaded, and the User
name & password are valid. On successfull validation the client can be
messaged to say that it can carry on using the url,driver,username
&password.
There are a number of side effects with this......
1) Assuming that X-D could be used as a server process, different users
might be "looking at" different db'es with the exact same structure
(redundancy, load balancing etc) where system integrity is handled via
replication. As such user A might request a document generated in exactly
the same way but from a different DB/URL.
2) Inserts/updates etc could then be done under the "Authority" of that
user.
3) It could be structured such that X-D can operate without these (e.g. in a
stored proceedure) so long as the properties file did contain the URL,
driver etc.
4) Again the login class would have to be made available to client builders
(i.e. as a Client Side Class).
5) X-D could then be tied into things such as Directory services to get the
info.....
So in essence all that would be needed would be the ability to call (e.g.
Transfer -toxml files.....,url,driver,userid,password)
Pooling connections etc should be thought of with this in the background.
4.4) Again needed to do the GUI.
5)
5.1) Have fun with thread safety......
5.2) The only public stuff should be that needed by the builder tools /
GUI'es & the actual operation. To a large degree this ties into 5.1 as
thread safety means (really) only have certain "entry points" which are then
checked for thread safety.
5.3) OK Again comes back to schemas.
5.4) No real view.
6) Weirdly ties into (2.9). i.e if using db2 the sql might be slightly
different for applying a Foreign key vs say Oracle vs say Access or MySQL
etc. Again if we were to think about the statements which would be required
from any/all db'es (thought should be given to a return of "not supported")
then if the DB is ID'ed then the values could be simply sent through a DB
specific processor (e.g.
createForeignKey(KEY_NAME,TABLE,FIELD,REF_TABLE,REF_FIELD, ACTIONS)
Such that on DB2 calling say:
createForeignKey("AAH_U_FK","NULLID.AAHEADNO","FK_USER_ID","NULLID.USERS","U
SER_ID","ON DELETE NO ACTION ON UPDATE NO ACTION")
Would give you:
ALTER TABLE NULLID.AAHEADNO ADD
CONSTRAINT AAH_U_FK
FOREIGN KEY (FK_USER_UID)
REFERENCES NULLID.USERS (
USER_UID) ON DELETE NO ACTION ON UPDATE NO ACTION;
Equally createPrimaryKey("NULLID.AAHEADNO","AAH_UID")
would give you:
ALTER TABLE "NULLID "."AAHEADNO"
ADD PRIMARY KEY
("AAH_UID");
Syntax for SQL Server, Sybase, Oracle, PostGreSQL etc might all be slightly
different but as long as you've ID'ed the DB then calling
createPrimaryKey("NULLID.AAHEADNO","AAH_UID") would be all you need to do.
It would be (IMHO) easy to write such DB specific classes (simple string
handling) but what would need carefull thought is what interfaces / methods
a "external_db" class would need to have.
7,8,9) No views. Never worked with SourceForge....but I know people who have
so I'll get onto them.
****Version 3****
1) Client classes? i.e best done by XML-DBMS or @ the client? If one were to
imagine X-D as being an XML DOC Sink/Source/server then why would it want to
do this? Give a client a more exact set of data?
2) Yup.
3) OK. Again comes back to Schema use.
4) 2 Stage commit.....
5) Comes back to Schemas
6) Ahhhh HA! <G>. Funnily enough......I have been examining exactly
this......
1) Some stuff would be easier e.g. Logon <>Session bean,Connection Pooling
etc.
2) Some usefull new EJB 2.0 capabilities e.g.Message Driven Bean (MDB) /JMS
& JTS (Java Transaction services). NB I really dislike the way that EJB'es
via their RPC capabilites have been misused as "Citrix for Java". I would
say that it is perfectly possible to simply use the Server side capabilites
w/o getting anywhere near the RPC stuff (the whole point of using xml is
it's ability to be asynchronous). If you wanted to construct an EJB client
which used that (e.g. for communication with X-D) then fine but it should be
possible simply via http/JMS.
i.e contruct it as a server process which runs within an EJB container
rather than as an EJB with all that entails as an example you could simply
make use of MDB'es.
7) Updating via Timestamp checking will probably scale the best. Handle
clashes / errors elsewhere (see Client Side Classes).
Document Caching:
If XML-DBMS were to simply write down to a folder (either from within a
trigger, server-side process,EJB) then all document retrieval could be via
http,JMS. You could then rely upon the JMS server, http server, proxy server
to do the load balancing / caching etc.
Pass-through:
No real views.
Client Side Classes:
It strikes me that @ least part of the utility in XML-DBMS might be gained
(as a sister project??) from the provision of client side classes to make
contruction of xml<>java client apps easy. In the update scenario's, it
might be possible to throw an error if the record has been updated b4 you
do. But..... how to handle it? i.e if someone had changed a field which you
weren't going to update anyway the whole transaction would fail.
However........if the update simply updated those fields which had changed
.......
XML-DBMS
check 1: "Is the current TS the same as the TS within the Table / the most
recently produced Doc" In either case XML-DBMS returns the new XML Doc. IF
Yes then update,return the new Doc & some kind of "OK" signal. If no then
return new XML Doc & "NOTOK" signal.
XML-DBMS job finished
Client classes:
Client has now 2 copies of the same doc with differing values. If any
"resubmit" is going to occur then it must use the new TimeStamp value(s)
from the newly returned doc.
Check2: OK | NOTOK ? If ok then show doc etc. If NOTOK then
Check3: "Are the fields I am wanting to update fields which have been
updated?" (i.e. check values) If NO then update just those fields.
If yes then (& here is scope for argument / individual decisions) update
just those where there has been no change OR simply chuck up a box saying
"someone has independantly updated this record etc" OR have an "Updated"
(Boolean) attached to each db based element such that the two can be merged
(i.e. put in the vals where the field Had NOT changed & set to updated = Yes
all those where it had such that the GUI / Wizard could be shown again /
updated with those, attention drawn to them (e.g. set the text colour to
red) & then the user would be asked if he/she wants to update again.
i.e ALL this (IMHO) should be done in the client where XML-DBMS would be
responsible for (a) Checking the TS & returning just the NEWEST doc +
Signal_Status such that the above operation can be performed.
i.e if the client app sends to XML doc to xml-dbms via "any means
neccessary" (e.g. JMS,http) then it expects to get a return of the new XML
Doc + a status signal. This would allow us to keep XML-DBMS as tight & fast
as possible so as to deal with as many clients as possible while still
allowing for update conflict resolution.
BTW By client classes I am not restricting things to "Visible GUI" clients
but any inc server-server comms.
Updates in XML-DBMS:
Scenario 1&2 see the client classes .....
Scenario 3:
This could be either simple or tricky.......Simple: stick to the foriegn
keys & use them as intended/used within a db i.e. you have an FK to part 456
held in the "parts" table. As such you could happily reuse the "part"
object/representation which
has a PK value of 456 assuming that the (2.1) Eliminate Root tables/classes
is done such that you can enter it @ any point.
The same goes for any lookup value & could form part of a optimization
strategy. E.g. if a lookup value (e.g. Part name/PK pair) is used in many
different screens & is updated infrequently then why repopulate it every
time? i.e. if someone actively requests a refresh of the data within a
lookup / all lookups then rebuild the XML file (or indeed tie the updating
of those fields to a Stored Proceedure which uses X-D to produce a new
file).
In other words **ALL** you might really be doing is setting FK_PART from 123
to 456. 1 field with a new reference.
Again the absence or presence of the timestamp value / primary key could be
enough to give x-d a fairly good guess wether something is an insert or an
update (or indeed if the document is "updateable" (e.g. no TS no Update.)
Scenario 4)
What I meant by the bound properties is down to whether all the named fields
are updated inc those where no change has occurred or whether ONLY the
changed fields would be updated. i.e @ the CLIENT end a note would be taken
of which fields had changed & thus which fields in the XML Doc would be
populated. This ties into the client class'es.
In short re Updating/Inserting:
We should use Timstamps @ the level of X-D itself as I think it would simply
be the fastest. High level conflict resolution should be carried out @ the
client. Insert/Update choice could be inferred by the presence / abscence of
the Pri_key & / Or the Timestamp (assuming that ONLY the DB gets to set
them).
If using X-D as a server side process then using JMS or possibly HTTP should
be the best bet (given firewalling etc) both for delivery from X-D to the
client & v.v.
Adam
I am a new user of XML-DBMS and am having problems with the map. I have a
DTD:-
<!ELEMENT xml (product+)>
<!ELEMENT product (size+, prices)>
<!ELEMENT size EMPTY>
<!ELEMENT aud EMPTY>
<!ELEMENT nzd EMPTY>
<!ELEMENT prices (aud, nzd)>
<!ATTLIST aud
now NMTOKEN #REQUIRED
was NMTOKEN #REQUIRED
>
<!ATTLIST nzd
now NMTOKEN #REQUIRED
>
<!ATTLIST product
sku NMTOKEN #REQUIRED
>
<!ATTLIST size
code NMTOKEN #REQUIRED
qty NMTOKEN #REQUIRED
>
and a copy of the XML I ultimately need to produce:-
<?xml version="1.0" ?>
<xml>
<product sku="1110029">
<size code="060" qty="15"/>
<size code="070" qty="13"/>
<price currency="AUD" now="7.50" was="8.50"/>
<price currency="NZD" now="10.50"/>
</product>
<product sku="1130274">
<size code="100" qty="15"/>
<size code="105" qty="13"/>
<size code="140" qty="23"/>
<price currency="AUD" now="30.00" was="35.00"/>
<price currency="NZD" now="45.00"/>
</product>
<product sku="3111010">
<size code="-xs" qty="15"/>
<size code="--s" qty="27"/>
<price currency="AUD" now="3.50" was="4.50"/>
<price currency="NZD" now="5.50"/>
</product>
</xml>
All the data is on the one table, when I run GENERATE MAP it tries to
create all sorts of tables. The table I'm using is called ITSOHF and some
of the fields are
sku = ITPRD
size code = ITSZ1/ITSZ2/ITSZ3 etc
qty = ITQTY1/ITQTY2/ITQTY3 etc.
Is it possible to create a map for this?
_____________________________
Laura Young
AS/400 Programmer
Sundata
Direct line 07 3004 7318
VISIT OUR WEB SITE to see how we can help you achieve your business goals.
http://www.sundata.com.au/
SUNDATA PRODUCTS & SERVICES
+ E-Business Solutions
+ Application Development and Support
+ Local and Wide Area Networks
+ Mid-Range Servers
+ Business Continuity Service
NOTICE - If you have received this message in error please notify Sundata
immediately and destroy the original message. Thank you. Sundata has
implemented anti-virus software, and whilst all care is taken, it is the
recipient's responsibility to ensure that any attachments are scanned for
viruses prior to use.
[Non-text portions of this message have been removed]
Very new to xml-dbms.
Using TransferResultSet on the sample table 'Sales'
using the command line options...
-s "select CUSTNUMBER FROM COLORADO.SALES" c:\colorado\sales_rs2.map
sales_out.xml
I am getting the following...
java.lang.ClassCastException
java.lang.Throwable()
java.lang.Exception()
java.lang.RuntimeException()
java.lang.ClassCastException()
void TransferResultSet.writeDocument(org.w3c.dom.Document,
java.lang.String)
void TransferResultSet.writeDocument(org.w3c.dom.Document,
java.lang.String)
void TransferResultSet.toXML(java.lang.String,
java.lang.String, java.lang.String, java.lang.String)
void TransferResultSet.main(java.lang.String [])
any suggestions?
Thanks
Laura
The short answer is that it is not possible to create a map for this,
but that it is possible to transfer the data and then transform the
result to what you want with the help of XSLT.
The long answer:
1) Your DTD does not match your XML. Therefore, I am going to assume
that the XML is correct and that the correct DTD is:
<!ELEMENT xml (product+)>
<!ELEMENT product (size+, price+)>
<!ATTLIST product
sku NMTOKEN #REQUIRED>
<!ELEMENT size EMPTY>
<!ATTLIST size
code NMTOKEN #REQUIRED
qty NMTOKEN #REQUIRED>
<!ELEMENT price EMPTY>
<!ATTLIST price
currency (AUD | NZD) #REQUIRED
now CDATA #REQUIRED
was CDATA #IMPLIED>
It appears that the "was" attribute is used only when currency is AUD.
Note that there is no way to express this in a DTD. (It might be
possible in XML Schemas, but I'm not sure about that.)
2) Because you are using a single table but have multiple code and
quantity columns, there must be a limit to how many there are of each
column. For example, you might have 10 of each. The same is true with
the was/now values of currencies. Furthermore, because there is only a
now attribute for NZD, I'm further assuming that you have columns like
AUDWAS1, AUDNOW1, and NZDNOW1 instead of CURR1, WAS1, and NOW1. Thus,
your table might look something like:
ITSOHF
------
ITPRD
ITSZ1
...
ITSZ10
ITQTY1
...
ITQTY10
AUDWAS1
...
AUDWAS10
AUDNOW1
...
AUDWAS10
NZDWAS1
...
NZDWAS10
3) XML-DBMS assumes that hierarchy in the database matches hierarchy in
the XML document. That is, when XML-DBMS generates a table structure
from your DTD, it will generate a separate table for any element that
has "children", either in the form of attributes or child elements. (In
the reverse direction, it assumes an element for each table, with
columns mapped to attributes or child elements.)
The reason for this is that each element with "children" maps to a
separate class, which then maps to a separate table. That is, the
structure of the XML document matches the structure in the database.
This is very easy to see visually in the case of child elements. (You
can use your imagination with attributes.)
<A> class A { table A
<B>...</B> String B; column B
<C>...</C> String C; column C
<D>...</D> String D; column D
</A> }
For example, using the above DTD, XML-DBMS will generate separate tables
for the product, size, and price elements. (In the case of the DTD
listed below, it would generate separate tables for the product, size,
prices, aud, and nzd elements.)
In your case, you have introduced structure in the XML document that
does not exist in the database. That is, you have grouped columns ITSZ1
and ITQTY1 together into attributes of the same size element. Although
you knew that these two columns deserved to be together, there is no way
for XML-DBMS to predict this.
Adding/eliminating structure that exists in XML and not in the database
is something that I have looked into, but did not implement due to
technical problems (impossibilities?). (For a rough explanation, see the
file PassThrough.txt in the directory in which you installed XML-DBMS.)
The only solution here is to use XSL Transformations (XSLT) to modify
the XML generated by XML-DBMS.
For example, I'll assume that you won't change your table. Thus,
XML-DBMS will generate XML that looks something like the following,
based on the table structure above. You can then use XSLT to match the
various xxx1, xxx2, etc. elements and place these together as attributes
of a size or price element.
<xml>
<product sku="...">
<code1>...</code1>
...
<code10>...</code10>
<qty1>...</qty1>
...
<qty10>...</qty10>
<audwas1>...</audwas1>
...
<audwas10>...</audwas10>
<audnow1>...</audnow1>
...
<audnow10>...</audnow10>
<nzdnow1>...</nzdnow1>
...
<nzdnow10>...</nzdnow10>
</product>
...
</xml>
The map for this will be pretty straight-forward -- you need an
IgnoreRoot for the xml element (with product as a PseudoRoot), a
ClassMap for product, and child PropertyMaps for each of the remaining
elements.
4) One other thing that is interesting to note here is that the table
contains multiple columns storing the same type of value (multiple
quantities, multiple currency values, etc.) In a completely normalized
database, these would be stored in separate tables. For example,
assuming the structure introduced in the XML, the tables would be:
product
sku
size
sku
code
qty
price
sku
currency
was
now
Grouping multiple values into a non-normal table is a reasonable thing
to do -- at the cost of some null values (when there are less values
than columns) you save joins, which are expensive. The obvious drawback
to this is that the number of possible values is limited to the number
of columns.
In XML-DBMS 1.0, I looked into supporting this, but cut it due to lack
of time and because DTDs can't easily limit the number of child elements
(each child must be enumerated separately). What is interesting about
this is that XML Schemas do support a limited number of child elements
-- that is, you can say that element A has exactly (or no more than)
three B elements as children. When the number of children is limited, it
is then quite reasonable to store them in the parent table. Therefore,
I've added this mapping feature to the version 3.0 and beyond spec.
Anyway, I hope this helps answer your question. Write back if you're
still confused -- there's a lot of info here.
-- Ron
lyoung@... wrote:
>
> I am a new user of XML-DBMS and am having problems with the map. I have a
> DTD:-
>
> <!ELEMENT xml (product+)>
> <!ELEMENT product (size+, prices)>
> <!ELEMENT size EMPTY>
> <!ELEMENT aud EMPTY>
> <!ELEMENT nzd EMPTY>
> <!ELEMENT prices (aud, nzd)>
> <!ATTLIST aud
> now NMTOKEN #REQUIRED
> was NMTOKEN #REQUIRED
> >
> <!ATTLIST nzd
> now NMTOKEN #REQUIRED
> >
> <!ATTLIST product
> sku NMTOKEN #REQUIRED
> >
> <!ATTLIST size
> code NMTOKEN #REQUIRED
> qty NMTOKEN #REQUIRED
> >
>
> and a copy of the XML I ultimately need to produce:-
> <?xml version="1.0" ?>
> <xml>
> <product sku="1110029">
> <size code="060" qty="15"/>
> <size code="070" qty="13"/>
> <price currency="AUD" now="7.50" was="8.50"/>
> <price currency="NZD" now="10.50"/>
> </product>
> <product sku="1130274">
> <size code="100" qty="15"/>
> <size code="105" qty="13"/>
> <size code="140" qty="23"/>
> <price currency="AUD" now="30.00" was="35.00"/>
> <price currency="NZD" now="45.00"/>
> </product>
> <product sku="3111010">
> <size code="-xs" qty="15"/>
> <size code="--s" qty="27"/>
> <price currency="AUD" now="3.50" was="4.50"/>
> <price currency="NZD" now="5.50"/>
> </product>
> </xml>
>
> All the data is on the one table, when I run GENERATE MAP it tries to
> create all sorts of tables. The table I'm using is called ITSOHF and some
> of the fields are
> sku = ITPRD
> size code = ITSZ1/ITSZ2/ITSZ3 etc
> qty = ITQTY1/ITQTY2/ITQTY3 etc.
>
> Is it possible to create a map for this?
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
The writeDocument methods are specific to individual parsers and
versions of those parsers. Therefore, what is probably happening is that
the parser you are using is either a different version from that which
the code expects or a different parser altogether. To fix this, check
the documentation for your parser and rewrite writeDocument as
necessary.
This problem arises because DOM does not define a standard way to print
a DOM Document. Thus, TransferResultSet can't just make a standard call.
Instead, different code is needed for each parser/version.
I also just noticed that I forgot to include parser version number in
the comments for the three writeDocument methods I've included. I think
it is version 2.0.2.8.0 for Oracle, version 1 for Sun, and version 1.1.0
for Xerces.
-- Ron
lyoung@... wrote:
>
> Very new to xml-dbms.
> Using TransferResultSet on the sample table 'Sales'
> using the command line options...
> -s "select CUSTNUMBER FROM COLORADO.SALES" c:\colorado\sales_rs2.map
> sales_out.xml
>
> I am getting the following...
> java.lang.ClassCastException
> java.lang.Throwable()
> java.lang.Exception()
> java.lang.RuntimeException()
> java.lang.ClassCastException()
> void TransferResultSet.writeDocument(org.w3c.dom.Document,
> java.lang.String)
> void TransferResultSet.writeDocument(org.w3c.dom.Document,
> java.lang.String)
> void TransferResultSet.toXML(java.lang.String,
> java.lang.String, java.lang.String, java.lang.String)
> void TransferResultSet.main(java.lang.String [])
>
> any suggestions?
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
I took a quick look at this and it's worth investigating in terms of
what features the transfer engine might need. A related product is
Castor (http://castor.exolab.org), which appears to implement JDO and
has a mapping language very similar to that of XML-DBMS. Not quite
related, but also interesting, is SOAP, which I've just started looking
at.
One thing to note about JDO and Castor is that the create actual
objects. Because XML-DBMS goes straight from database to XML without
creating any objects, we will probably be limited in our ability to
actually use products like Castor. That is, we'll probably end up
duplicating a lot of what they have already done.
Whether the lack of actual objects in XML-DBMS is good or bad really
depends on the application. If you're using XML-DBMS as a way to get
data and using the resulting XML to populate objects, you might be
better off with Castor. On the other hand, if you're using XML-DBMS to
send data to a remote (and possibly unknown) application, you're
probably better off with XML-DBMS.
Where JDO and Castor are important to XML-DBMS is that many of the
features are the same. Taking the view of XML as simply a serialized
object, all three have the same worries about connection pooling, update
collisions, transactions, etc. Thus, it is useful to look at these
products while thinking about design.
-- Ron
adam flinton wrote:
>
> Dear All,
>
> I am currently just starting to look @ Java Data Objects (JDO)
>
> Has anyone else looked @ them? They may (may) form something to think about
> for version 3.
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
See below:
adam flinton wrote:
> I have been looking @ how other dbms interactive systems handle Updates
> (e.g. EJB CMP systems).
>
> I reckon that the timestamp added by the dbms on Insert & then amended on
> insert is going to be the best way. However a thought has occurred.
I tend to agree.
> If one could assume that an XML "message" (i.e. a doc sent to the dbms for
> inclusion in the dataset) with a Pri_key is an update whereas where the
> pri_key field is null is an insert........then surely one could also assume
> that any document without a timestamp is either an insert or is read-only.
>
> i.e. Prikey but no ts = readonly
> No Pri_key = insert (whether with or w/o a TS)
> Pri_Key + TS = update.
Unfortunately, this assumes that the primary key and timestamp are not
data. That is, they will be generated by the database and won't be
included in the document except when the document is meant to be
updated. Although this is good database design, not everybody follows
good database design and I'm not yet convinced that we can't include
(just about) everybody. That is, I should be able to use a sales order
number as a primary key and still insert/update/delete the document.
> BTW I've also been looking @ the schema docs now that schema's are getting
> to be nearly adopted. It seems obvious to me that they are heavily aimed at
> representing database based records.
>
> Should we aim to move wholeheartedly to Schema's for version 2? The
> advantages seem (to me) to be so clear over DTD's (e.g. type checking & the
> handling of "complex types").
I strongly agree -- this is one of those things that, when I read it, my
reaction was, "Boy, that's obvious. Why didn't I think of that?"
What this really means is that the map language and objects and the
transfer code should support as much of the functionality found in
schemas as possible: inheritance, the minOccurs and maxOccurs
attributes, simple and complex data types, etc.
One consequence of this is that it's going to take longer to produce 2.0
than planned, but I think it's worth it. Note that this does not
necessarily mean that we have to support all of schemas in 2.0. What it
means is that 2.0 should support the primary features of schemas (yet to
be decided upon) and should provide the framework for supporting all of
schemas in the future without any backwards incompatibilities.
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
See below:
> 2.4) My main thought is why DTD instead of Schema's? If you could get the
> typing (as an example) of a given element via the DB metadata then why not
> persist such information? It should be reasonably easy to map SQL/JDBC
> typing to the XML metadata.
Duh. You're very right. This will mean writing a set of schema objects.
I think it also means linking schema objects to database metadata
objects (Table, Column, etc.), probably through intermediate map
objects.
> 2.9) This will have to be designed to be modular such that particular
> foibles of particular DB'es can be compensated for. IMHO if this is
> carefully designed then it could be used within the DB > MAP generation as
> most/all serious DB'es have structures
> (e.g. the SYS tables) which allow for querying in order to find loads of
> info for easy building (e.g. Pri_key column for a given table, view or a
> table (i.e updatable, not updatable ), foreign key relationships etc. i.e if
> you were to ID the DB as say Oracle 8.0 or DB2 V7.1 then the SQLDB > MAP/
> Schema builder could use class'es / JDBC Queries to find PK & FK info etc. I
> could happily build something like that (& have been looking @ doing so) for
> DB2 but so long as the interfaces were clearly built (e.g. getForiegn_keys()
> where the arg is a table name (fully qualified)
The name resolution code will definitely provide a hook so that
applications can provide their own code.
The map factory for database schema probably won't need such a hook. I
suspect that everything we need can be retrieved from JDBC. (What will
be needed is on the other end -- that is, hooks for constructing CREATE
TABLE statements using the correct SQL dialect.)
> 3)
> 3.1) YES!!!! IMHO housing XML-DBMS on the client is simply as mistake (e.g.
> updating problems multiple copies of what only needs to be held once @ the
> center etc.etc.
>
> My idea is along the lines of building clients which have NO JDBC in them @
> all. JMS OK, RPC/EJB/CORBA OK. i.e the system works @ a ****Document
> level**** & the clients are built to deal with documents. I reckon XML-DBMS
> should be capable of being housed in 3 places (all server-side) (1) As a
> sored proceedure in a DBMS trigger (insert of update) (2) As a standalone
> server process (3) Within an EJB Container.
In a client-server environment, I agree. Communication probably consists
of the XML document plus commands on what to do with it. (I suspect SOAP
could be used here -- that is, XML-DBMS could be driven by SOAP
applications on the server and the client.)
> 3.2 & 3.3) (a) @ a simple level (& in terms of efficiency (in case of
> scaling)) the timestamp option is the best. The "values" scenario has me
> interested in terms of client side classes (see "Client Side Classes"). One
> point which is that rather like having the Pri_key for every table
> referenced, you would need the TS for every table reff'ed OR check against
> the produced document (assuming a new one is produced following every
> update). Another quick question (probably leading to a loooong answer) is
> Can the update/insert statement be constructed so as to only update / insert
> on the fields/columns which require it? If so then the values approach
> becomes much stronger.
Update statements can and will be constructed this way. Note that if
values are used for optimistic locking, then the old values would still
appear in the WHERE clause.
Inserts should always have all columns. Any columns for which no value
is provided in the XML document will be set to null.
> 4.1) If the parser & the JDBC Info can be abstracted / loaded from external
> sources then I will start on the transfer GUI initially.
Yes! Yes! Yes! I can't wait to play with it.
> 4.3)Here I have a number of points / pointlets
>
> a) Password should be there even if the GUI never writes it (i.e. it could
> be included by hand editing the properties file. The main reason for this
> would be for use in pure serverside stuff (e.g. running XML-DBMS as a stored
> procedure called from within a trigger in the dbms).
Isn't this a severe breach of security? I'm not sure I want to allow
that.
> b) I have done this for JDBC access for db'es running from Oracle thorough
> Db2 to Access. the url part is different but users will just have to look
> that up (much like they'd have to look up what the DB name was & what port
> the JDBC handler might be running on (if using lightweight / net JDBC
> drivers)). Simply put the things like user name/ password are ignored where
> not required (e.g. Access). This is no big thing however it does lead to
> something which needs thought.
We should make this as easy for users as possible. One way would be to
have a configurable GUI based on a properties file. We could then
provide properties files for as many databases as we can. This makes
life easy for the majority of users and makes it possible for the odd
cases.
> c) Logon in general.
>
> It strikes me (for a number of reasons) that we should construct XML-DBMS
> such that it can be called with all the external settings (esp the UserID &
> Password). i.e. It is common in "audited systems" to (a) record the last
> update / insert timestamp (needed anyway by us for update) & (b) to record
> the User who made the change. This last bit is often vital in terms of
> finding the record you just inserted e.g. you have a table with fields
> Pri_Key,text,UserID,LastChange_TS. You insert into that table. How do you
> then find which record you just inserted (e.g. for inserting child elements
> into child tables & setting the foreign key )? Assuming Pri_Key is some form
> of autoincrementing field (or you could use the timestamp) you then simply
> have to call "select max(Pri_key) from table where userid =". Implementing
> this should be easy enough as you simply use the same logon box as with the
> GUI tools such that hitting "OK" calls a verification select just to test
> that the db is @ that URL, the driver can be found & loaded, and the User
> name & password are valid. On successfull validation the client can be
> messaged to say that it can carry on using the url,driver,username
> &password.
I lost you here. To start with, you want the transfer engine API to
include methods/parameters for all necessary information, including user
name and password. I tend to agree with this, although it's not yet
clear to me if this is the responsibility of the transfer engine or the
calling application. For example, if the transfer engine API only
requires a Connection, then the application, not the transfer engine,
has this information.
Next, you want sufficient information returned to the application to
retrieve the just-inserted/updated document. Currently, a DocInfo object
is returned for this purpose. Note that this obviously doesn't work in
the case of DBMS-generated primary keys, such as Oracle ROWIDs, which
are a known problem anyway.
Where I really lost you was on the last bit. Are you asking for a method
on the engine to simply test the connection?
> There are a number of side effects with this......
> 1) Assuming that X-D could be used as a server process, different users
> might be "looking at" different db'es with the exact same structure
> (redundancy, load balancing etc) where system integrity is handled via
> replication. As such user A might request a document generated in exactly
> the same way but from a different DB/URL.
> 2) Inserts/updates etc could then be done under the "Authority" of that
> user.
Are you asking for the transfer engine to keep track of authorization
information? Might be too complex for 2.0.
> 3) It could be structured such that X-D can operate without these (e.g. in a
> stored proceedure) so long as the properties file did contain the URL,
> driver etc.
Good point. Again, how do we handle the security breach of having an
unencrypted password in a properties file?
> 4) Again the login class would have to be made available to client builders
> (i.e. as a Client Side Class).
I think I see where you're going, now. Do you mean that applications can
log in to the engine and the engine keeps per-login state information?
That would probably make sense, as it would allow the engine to be
thread safe, with each application passing in a session ID on the other
calls.
> 5.1) Have fun with thread safety......
Is it that bad? The only place I'm worried about it is in SAXToDBMS --
every SAX application I've written has a large number of global (class)
variables and there is no way to pass these from method to method since
the parser obviously doesn't know about them.
> 6) Weirdly ties into (2.9). i.e if using db2 the sql might be slightly
> different for applying a Foreign key vs say Oracle vs say Access or MySQL
> etc. Again if we were to think about the statements which would be required
> from any/all db'es (thought should be given to a return of "not supported")
> then if the DB is ID'ed then the values could be simply sent through a DB
> specific processor (e.g.
> createForeignKey(KEY_NAME,TABLE,FIELD,REF_TABLE,REF_FIELD, ACTIONS)
>
> [snip]
>
> It would be (IMHO) easy to write such DB specific classes (simple string
> handling) but what would need carefull thought is what interfaces / methods
> a "external_db" class would need to have.
Agreed.
> ****Version 3****
>
> 1) Client classes? i.e best done by XML-DBMS or @ the client? If one were to
> imagine X-D as being an XML DOC Sink/Source/server then why would it want to
> do this? Give a client a more exact set of data?
Unfortunately, I've revamped the version 3 spec and can't remember what
#1 was. Assuming it was a query language, then the answer is yes, to
give the client exactly what they want. For example, they might want all
sales orders with a total value greater than USD 1000.
> 4) 2 Stage commit.....
Added to spec.
> 6) Ahhhh HA! <G>. Funnily enough......I have been examining exactly
> this......
Not surprising -- I pulled the idea from one of your emails :)
> 1) Some stuff would be easier e.g. Logon <>Session bean,Connection Pooling
> etc.
I'm not sure this is true. I haven't looked at EJB yet, but a lot of
this stuff might occur in a place where we don't have any control over
it. For example, if EJB has their own methods to store the data in a
bean and these are roughly storeBeanProperties, this won't work for us.
The reason is that XML-DBMS needs a Connection and does all the storage
work itself. I have a sneaking suspicion that we're going to end up
duplicating a lot of the work that's in EJB and JDO.
> 2) Some usefull new EJB 2.0 capabilities e.g.Message Driven Bean (MDB) /JMS
> & JTS (Java Transaction services). NB I really dislike the way that EJB'es
> via their RPC capabilites have been misused as "Citrix for Java". I would
> say that it is perfectly possible to simply use the Server side capabilites
> w/o getting anywhere near the RPC stuff (the whole point of using xml is
> it's ability to be asynchronous). If you wanted to construct an EJB client
> which used that (e.g. for communication with X-D) then fine but it should be
> possible simply via http/JMS.
> i.e contruct it as a server process which runs within an EJB container
> rather than as an EJB with all that entails as an example you could simply
> make use of MDB'es.
As above -- can we actually use this stuff?
> Document Caching:
>
> If XML-DBMS were to simply write down to a folder (either from within a
> trigger, server-side process,EJB) then all document retrieval could be via
> http,JMS. You could then rely upon the JMS server, http server, proxy server
> to do the load balancing / caching etc.
Can you point me to some basic documentation on this stuff? I'm totally
ignorant here.
> Client Side Classes:
>
> It strikes me that @ least part of the utility in XML-DBMS might be gained
> (as a sister project??) from the provision of client side classes to make
> contruction of xml<>java client apps easy. In the update scenario's, it
> might be possible to throw an error if the record has been updated b4 you
> do. But..... how to handle it? i.e if someone had changed a field which you
> weren't going to update anyway the whole transaction would fail.
> However........if the update simply updated those fields which had changed
> .......
>
> XML-DBMS
> check 1: "Is the current TS the same as the TS within the Table / the most
> recently produced Doc" In either case XML-DBMS returns the new XML Doc. IF
> Yes then update,return the new Doc & some kind of "OK" signal. If no then
> return new XML Doc & "NOTOK" signal.
>
> XML-DBMS job finished
>
> Client classes:
>
> Client has now 2 copies of the same doc with differing values. If any
> "resubmit" is going to occur then it must use the new TimeStamp value(s)
> from the newly returned doc.
>
> Check2: OK | NOTOK ? If ok then show doc etc. If NOTOK then
> Check3: "Are the fields I am wanting to update fields which have been
> updated?" (i.e. check values) If NO then update just those fields.
>
> If yes then (& here is scope for argument / individual decisions) update
> just those where there has been no change OR simply chuck up a box saying
> "someone has independantly updated this record etc" OR have an "Updated"
> (Boolean) attached to each db based element such that the two can be merged
> (i.e. put in the vals where the field Had NOT changed & set to updated = Yes
> all those where it had such that the GUI / Wizard could be shown again /
> updated with those, attention drawn to them (e.g. set the text colour to
> red) & then the user would be asked if he/she wants to update again.
>
> i.e ALL this (IMHO) should be done in the client where XML-DBMS would be
> responsible for (a) Checking the TS & returning just the NEWEST doc +
> Signal_Status such that the above operation can be performed.
> i.e if the client app sends to XML doc to xml-dbms via "any means
> neccessary" (e.g. JMS,http) then it expects to get a return of the new XML
> Doc + a status signal. This would allow us to keep XML-DBMS as tight & fast
> as possible so as to deal with as many clients as possible while still
> allowing for update conflict resolution.
>
> BTW By client classes I am not restricting things to "Visible GUI" clients
> but any inc server-server comms.
I'll have to think about it some more, but think I agree with the
responsibilities you assign to the client and to XML-DBMS. I also agree
that the client stuff might make a useful set of helper classes.
> Updates in XML-DBMS:
>
> Scenario 1&2 see the client classes .....
>
> Scenario 3:
>
> This could be either simple or tricky.......Simple: stick to the foriegn
> keys & use them as intended/used within a db i.e. you have an FK to part 456
> held in the "parts" table. As such you could happily reuse the "part"
> object/representation which
> has a PK value of 456 assuming that the (2.1) Eliminate Root tables/classes
> is done such that you can enter it @ any point.
The tricky part for me about all of this is how the user specifies how
stuff should be handled. One easy heuristic is that if the PK is in the
child, then duplicates are OK and it's safe to use an existing row.
> Scenario 4)
>
> What I meant by the bound properties is down to whether all the named fields
> are updated inc those where no change has occurred or whether ONLY the
> changed fields would be updated. i.e @ the CLIENT end a note would be taken
> of which fields had changed & thus which fields in the XML Doc would be
> populated. This ties into the client class'es.
As far as I'm concerned, only changed fields should be updated in the
database.
> In short re Updating/Inserting:
>
> We should use Timstamps @ the level of X-D itself as I think it would simply
> be the fastest. High level conflict resolution should be carried out @ the
> client. Insert/Update choice could be inferred by the presence / abscence of
> the Pri_key & / Or the Timestamp (assuming that ONLY the DB gets to set
> them).
As I pointed out separately, I'm not yet convinced that primary key and
timestamp can be used for these heuristics. The problem is that these
might be actual data (e.g. a sales order number and date) and therefore
always present.
I do agree that high-level resolution should be left to the client.
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
I am using the MapFactory_DTD class to generate a map from a DTD.
Is there a way to modify the mapping language so that a nested element with
attributes but no child elements can be represented in one table (ie., so
that a separate table is not created for each attribute)? I have partially
done this by modifying the isClass method of MapFactory_DTD to return only
elements that have child elements and not return elements that have child
attributes.
return (!elementType.children.isEmpty());
// ||!elementType.attributes.isEmpty());
>From: Ronald Bourret <rpbourret@...>
>Reply-To: xml-dbms@egroups.com
>To: xml-dbms@egroups.com
>Subject: Re: [xml-dbms] Comments on V2.0 Spec + V3 Early thoughts
>Date: Thu, 05 Oct 2000 17:48:26 -0700
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
I assume what you want is to be able to store element B and attributes C
and D in the following in the table for A:
<A>
<B C="cccc" D="dddd">bbbb</B>
<E>eeee</E>
</A>
Is this correct? If so, then the answer is that this is not currently
possible. If you read this list often, you will notice that this is a
special case of wanting to "pass through" an element, which is not yet
implemented. That is, from the point of view of XML-DBMS, the above XML
is equivalent to:
<A>
<B>
<Bvalue>bbbb</Bvalue>
<C>cccc</C>
<D>dddd</D>
</B>
<E>eeee</E>
</A>
(From a theoretical standpoint, it is easy to see why XML-DBMS behaves
as it does and why you can't do what you want. You would like to view B
as a scalar property of A, but you would also like B to have properties
of its own (attributes). But only classes can have properties, so you
can't do both. However, I sympathize with your situation, as this sort
of construction is quite common in XML. This case, as well as the
address case shown in PassThrough.txt, are slowly convincing me that we
should have a limited form of pass-through in 3.0.)
Therefore, you have two choices:
1) Use XSLT to transform your XML to the following before you pass it to
XML-DBMS:
<A>
<B>bbbb</B>
<C>cccc</C>
<D>dddd</D>
<E>eeee</E>
</A>
In this case, you will also need to modify the DTD before passing it to
MapFactory_DTD.
2) Use the change you have made. An unfortunate side effect of this
should be (I haven't checked the code) that the attribute values aren't
mapped to the database and the data in them can't be transferred.
pareena shah wrote:
>
> I am using the MapFactory_DTD class to generate a map from a DTD.
>
> Is there a way to modify the mapping language so that a nested element with
> attributes but no child elements can be represented in one table (ie., so
> that a separate table is not created for each attribute)? I have partially
> done this by modifying the isClass method of MapFactory_DTD to return only
> elements that have child elements and not return elements that have child
> attributes.
>
> return (!elementType.children.isEmpty());
> // ||!elementType.attributes.isEmpty());
>
> >From: Ronald Bourret <rpbourret@...>
> >Reply-To: xml-dbms@egroups.com
> >To: xml-dbms@egroups.com
> >Subject: Re: [xml-dbms] Comments on V2.0 Spec + V3 Early thoughts
> >Date: Thu, 05 Oct 2000 17:48:26 -0700
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
>
> To Post a message, send it to: xml-dbms@eGroups.com
>
> To Unsubscribe, send a blank message to: xml-dbms-unsubscribe@eGroups.com
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
Adam Flinton's messages about client- and server-side classes made me
realize that I have no idea how people are using XML-DBMS. Is it part of
a distributed object system? A simple way to store XML documents? A bulk
loader for data? Part of a Web publishing system?
How XML-DBMS is used is important -- it affects the architecture and
features of the 2.0 release, especially in the transfer engine.
So that we can do a better job designing XML-DBMS 2.0, I'd appreciate it
if you wrote a quick message explaining how you use XML-DBMS, what 2.0
features you intend to use, and what features you need that are not in
2.0.
That's about 170 responses I'm expecting... :)
Thanks,
-- Ron Bourret
Mainly as a simple way to load/extract XML docs but in the context of
data transfer between applications.
So the 2.0 features would be:
- the nice GUI :-)
- XML Schemae
- Object IDs in leaf nodes
- Transfer engine
- Updates/deletes
- Database/parser independence
Regards,
Emmanuel
-----------------------
Norkom Technologies Ltd.
www.norkom.com
Hello,
I get the following error when running transfer:
de.tudarmstadt.ito.xmldbms.KeyException: Can't call commit when
autocommit=true
at
de.tudarmstadt.ito.xmldbms.helpers.KeyGeneratorImp
l.initialize(KeyGeneratorImpl.java:123)
at Transfer2.toDBMS(Transfer2.java:145)
at Transfer2.main(Transfer2.java:113)
I have created the necessary table and column for the jey generation.
I use mysql.
BTW is there a way to turn off this feature? mysql has autoincrement,
can xm-dbms use that?
Thanks
--
ayman
1) As a workaround, comment out the call to conn.commit() at the end of
KeyGeneratorImpl.getHighKey().
2) You will probably have problems with DOMToDBMS as well. For a
workaround, see http://www.eGroups.com/message/xml-dbms/127.
3) Contact your JDBC driver vendor. Connection.commit() should not throw
an error in this case -- calling commit should simply be a no-op.
Although the JDBC spec is vague on this point, ODBC (which is based on
the same international standard) explicitly states that this is not an
error. Furthermore, the only real effect of throwing an error here is to
needlessly cause applications to break.
4) You only need KeyGeneratorImpl if you want XML-DBMS to generate key
values for you. Unfortunately, XML-DBMS cannot use the auto-incrementing
column as a primary key. The problem is that, after an insert, DOMToDBMS
would need to reselect the just-inserted row to get the new key value so
it could be used as a foreign key in child tables. It currently does not
do this. This is listed as a possible feature in 2.0 and would be used
by Oracle ROWIDs as well.
Ayman Akt wrote:
>
> Hello,
>
> I get the following error when running transfer:
>
> de.tudarmstadt.ito.xmldbms.KeyException: Can't call commit when
> autocommit=true
> at
> de.tudarmstadt.ito.xmldbms.helpers.KeyGeneratorImp
> l.initialize(KeyGeneratorImpl.java:123)
> at Transfer2.toDBMS(Transfer2.java:145)
> at Transfer2.main(Transfer2.java:113)
>
> I have created the necessary table and column for the jey generation.
> I use mysql.
>
> BTW is there a way to turn off this feature? mysql has autoincrement,
> can xm-dbms use that?
>
> Thanks
>
> --
> ayman
>
>
> To Post a message, send it to: xml-dbms@eGroups.com
>
> To Unsubscribe, send a blank message to: xml-dbms-unsubscribe@eGroups.com
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
I just thought I'd mention this as I came across it on the "xmlhack"
site.
The site says - " Kimbro Staken and Lars Martin announced the
creation of XML:DB, an initiative for the "development of
standardized technologies for managing the data in XML Databases". "
The URL for the article is http://www.xmlhack.com/read.php?item=828
Could be worth keeping an eye on ... :-)
Sorry about the unstructured nature of this but....
1) I spotted a mail re XML:DB. Should someone contact them & see if there's
any commonality?
2) Should we contact people who are involved with Enhydra (such as Brett
Mclaughlin) as they seem to be address a lot of the same problems as us &
quite frankly I have spotted a bunch of code which could be lifted
wholesale. As an example see this Javaworld article:
http://www.javaworld.com/javaworld/jw-10-2000/jw-1013-validation2.html
I would think that it would be best coming from Ronald. Possibly get their
take on JAXP & JDOM......i.e. say to them "have a look @ this & let us know
if you've already got a bunch of code which address'es these probs...."
3) Who is tidying up the XML Parser / JDBC extraction to outside settings /
files such that recompilation need not occur in case of swapping db or
parser? I would like to get to this stage b4 shoving together a GUI.
4) Has anyone given any thought to the possible use of SQLJ? I ask this
simply because the semi-compiled nature of SQLJ would lend itself to
XML-DBMS (i.e it should be faster than JDBC).
5) I have been looking @ a product called DbVizualizer
http://www.pureit.se/products/dbvis/ mostly for "inspiration" regarding the
SQLDB > XML part of XML-DBMS.
It's an excellent product & has me thinking......
<Sneaky Mode> I could try & redo what they have already done but what could
be done....is if they were willing they could get the bit of the product
(inc GUI) needed to produce the XML map files etc from the SQL DB & open
Source it as part of the XML-DBMS & then also include that within their tool
such that if you needed the DB design stuff as well the XML-DBMS could
become a Menubar / tab item......
i.e we need a subset of what they have (i.e. a GUI for looking @ the Db & a
visual builder for the SQL expressions needed to create the XML<>SQL
Mapping) & they want to sell a DB visual design tool soooooooooooo....if
their design tool supported XML-DBMS then that would form part of their
sales pitch while those amongst us who had no need for the DB design part
would have a visual builder for creating Map files. </Sneaky Mode>
Have a look @ DBViz......it might be worth their while......especially if
being able to produce & consume XML docs becomes the vital part of any
DBA'es life that I think it will.
For instance the ability as set out in
http://www.pureit.se/products/dbvis/images/dbvis-5.gif would be usefull in
the XML-DBMS map building.....
6) As a subset of (5) Does anyone know if in JDBC there is some metadata
which returns the DB & it's version (e.g. Oracle 8i or DB2 V7.1?)
7) Here's a real tangential / future gazing point which suddenly struck me
over the weekend........Deep Breath....
I have been messing around with J2EE as part of my company's evaluation
process. I have come to the conclusion that Entity beans are a dark plot by
Sun & IBM to sell more powerfull servers as they are horrendous (seriously
imagine creating an object for each row in one table where that table might
have 500k rows...then imagine that each item has say an average of ten child
rows held in a related table (e.g. Orders & Order lines)..........now
visualize 500 people interacting with that...etc.etc).
Reminds me of IBM's SanFrancisco Framework (& I suspect that much of EJB'es
have come from there).
However XML-DBMS creates these map objects which are then written into
XML......If one were to be running XML-DBMS as a server process (either
within an EJB server or without) then one could imagine calling transfer
-tomemory (either from DBMS or from XML)............I say that because I
think that the resultset / result idea is a better one than the lunacy
known as the Entity Bean.
Adam
--- In xml-dbms@egroups.com, adam flinton <aflinton@a...> wrote:
>
>
> Sorry about the unstructured nature of this but....
>
> 1) I spotted a mail re XML:DB. Should someone contact them & see if
there's
> any commonality?
>
Mmm ... I fully agree ... :-) ( I'm a relative newbie to XML ,
however, so I'm kinda reluctant myself to do the "approaching" :-)
Maybe someone like Ronald? ( Sorry if that puts you in the hot seat,
Ronald :-P )
Some very good points made in your posting, Adam. I looked at the
DbVis site and was very interested. Have now bookmarked it for
posterity...
I tried sending them email last week, but the message was returned as
"User unknown". I'll try writing directly to the people involved this
week.
Unless they can get the big boys (Oracle, Micrsoft, IBM, etc.) to play,
I'm not sure how far they'll get towards their goal of "standardized
technologies", but I suspect that they can provide more input in trying
to solve the problems we (and everybody else in this field) are working
on.
-- Ron
andy.elvey@... wrote:
>
> --- In xml-dbms@egroups.com, adam flinton <aflinton@a...> wrote:
> > 1) I spotted a mail re XML:DB. Should someone contact them & see if
> there's
> > any commonality?
> >
>
> Mmm ... I fully agree ... :-) ( I'm a relative newbie to XML ,
> however, so I'm kinda reluctant myself to do the "approaching" :-)
>
> Maybe someone like Ronald? ( Sorry if that puts you in the hot seat,
> Ronald :-P )
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
adam flinton wrote:
>
> 2) Should we contact people who are involved with Enhydra (such as Brett
> Mclaughlin) as they seem to be address a lot of the same problems as us &
> quite frankly I have spotted a bunch of code which could be lifted
> wholesale. As an example see this Javaworld article:
>
> http://www.javaworld.com/javaworld/jw-10-2000/jw-1013-validation2.html
>
> I would think that it would be best coming from Ronald. Possibly get their
> take on JAXP & JDOM......i.e. say to them "have a look @ this & let us know
> if you've already got a bunch of code which address'es these probs...."
>
Probably a good idea. Most interesting is probably any code they have
that generates Java objects from XML Schema (the Sun Java Data Binding
spec). I've looked at this spec before, but only today really realized
that it does exactly what we need -- maps XML Schema to objects. We can
then extend it to map to RDBMSs as needed.
Enhydra is in Santa Cruz (where I live), so I might be able to talk to
them in person.
> 3) Who is tidying up the XML Parser / JDBC extraction to outside settings /
> files such that recompilation need not occur in case of swapping db or
> parser? I would like to get to this stage b4 shoving together a GUI.
I was kind of hoping you were doing this :)
Here's what needs to be done. Note that for (1) and (2), the UI probably
only needs to prompt for the name of the properties file, which will be
either edited by hand or through a separate dialog box. (I say a
separate dialog box rather than the main UI since this is something that
will be set up only once, but used many times.)
1) Put the database information in database-specific properties files.
We need the following properties:
URL
UserName
JDBCDriverClass
I don't like the idea of putting a password in a properties file, so the
user should either have to input it (through the UI) or pass it in
programmatically (when bypassing the UI). Note also that I'm not sure I
like the idea of password as a command line option, as this means it's
visible. (On the other hand, I do like the idea of all other properties
as command line options, which allows batch use of Transfer.)
In the future, we might have GUI configuration files for individual
databases or simply use JDBC 2.0 DataSources. Either would simplify
things for the end user. (JDBC 2.0 DataSources allow you to set all the
properties ahead of time and give them a logical name, just like ODBC
data sources. Note that our property files are essentially the same as
file data sources in ODBC, except that they're not registered in a
central naming service.)
2) Put the parser information in a properties file:
NamespaceQualifierClass: Name of a class that implements the
NamespaceQualifier interface
DocumentFactoryClass: Name of a class that implements the
DocumentFactory interface
SAXParserClass: Name of a class that implements the getSAXParser method
(currently found in Transfer)
OpenDocumentClass: Name of a class that implements the openDocument
method (currently found in Transfer)
WriteDocumentClass: Name of a class that implements the writeDocument
method (currently found in Transfer)
Note that in 2.0, we will probably come up with more sensible interfaces
for these, resulting in less classes. For example, we might combine
DocumentFactory, openDocument, and writeDocument into a single
DocumentIO interface. (I'm not going to try to define these interfaces
yet, as all the requirements are not yet clear in my mind. The above
should be enough to start work on the UI.)
3) It is not clear where the KeyGenerator implementation goes. This is
certainly at a different level than data source information and it is
not related to the parser. I suspect that, as 2.0 progresses, we are
likely to separate a lot of the stuff that is currently listed under
Options in the map file into a separate options file, and that
KeyGenerator will go there. In the GUI, it would probably be a good
thing to have an Options button with an Options dialog box for setting
this sort of thing.
As to the UI itself, I'd imagined something like the following (feel
free to modify this as you wish).
Database Configuration Screen:
------------------------------
Configuration File Name: _______ (Browse Button)
JDBC Driver Class: ________
Database URL: ________
Username: ________
Parser Configuration Screen, Options Configuration Screen:
----------------------------------------------------------
(similar to database configuration)
Data Transfer Screen:
---------------------
Configuration:
Database Properties File: _________ (Browse Button)
Parser Properties File: __________ (Browse Button)
Options File: __________ (Browse Button)
Data Transfer:
[] XML To Database
[] Database To XML
XML Document: ________ (Browse Button)
Map Document: ________ (Browse Button)
Root Table: _______
Column: _______
Value: _______
Note that the Root Table/Column/Value stuff is a bit tricky from a UI
standpoint. There can be multiple root tables and, for each table,
multiple root columns/values. I'm not sure how to show this in the GUI.
> 4) Has anyone given any thought to the possible use of SQLJ? I ask this
> simply because the semi-compiled nature of SQLJ would lend itself to
> XML-DBMS (i.e it should be faster than JDBC).
As far as I can figure out, we can't use it. SQLJ is embedded SQL for
Java. This means that you embed SQL statements in Java code, then run a
preprocessor over the code to turn these into Java method calls.
There are two problems with this. First, the SQL statements have to be
hard coded. XML-DBMS generates SQL at run time, which is to be expected
since it doesn't know anything about the tables it's transferring data
to/from.
Second, I assume that the code needs to be recompiled for each database
you want to connect to. (This is how other types of embedded SQL work.)
It is to get around the above problems that ODBC (and then JDBC) were
invented. As to speed, there shouldn't be much difference. Remember, the
result is that the program is making method calls to an API. (In the
case of SQLJ, this will presumably be the native API.) Assuming the JDBC
driver is well written, the speed should be comparable. (It is
interesting to note along these lines that the ODBC driver from MS for
SQL Server was, in many cases, faster than the native API.)
> 5) I have been looking @ a product called DbVizualizer
> http://www.pureit.se/products/dbvis/ mostly for "inspiration" regarding the
> SQLDB > XML part of XML-DBMS.
>
> It's an excellent product & has me thinking......
>
> <Sneaky Mode> I could try & redo what they have already done but what could
> be done....is if they were willing they could get the bit of the product
> (inc GUI) needed to produce the XML map files etc from the SQL DB & open
> Source it as part of the XML-DBMS & then also include that within their tool
> such that if you needed the DB design stuff as well the XML-DBMS could
> become a Menubar / tab item......
>
> i.e we need a subset of what they have (i.e. a GUI for looking @ the Db & a
> visual builder for the SQL expressions needed to create the XML<>SQL
> Mapping) & they want to sell a DB visual design tool soooooooooooo....if
> their design tool supported XML-DBMS then that would form part of their
> sales pitch while those amongst us who had no need for the DB design part
> would have a visual builder for creating Map files. </Sneaky Mode>
>
> Have a look @ DBViz......it might be worth their while......especially if
> being able to produce & consume XML docs becomes the vital part of any
> DBA'es life that I think it will.
>
> For instance the ability as set out in
> http://www.pureit.se/products/dbvis/images/dbvis-5.gif would be usefull in
> the XML-DBMS map building.....
It does look like a nice product. As you point out, we only need a small
part of this product -- mostly the graphical table mapper. I'll write
them and see what they think, but they're a commercial product, so I
wouldn't get my hopes up.
Note that at the moment we can't write this application. The reason is
that it is essentially a visual map factory and it can't be built until
after maps have been redesigned (rewritten).
However, we can start thinking about what the UI looks like right now,
which would probably help in the map redesign, too. Note that, while a
completely graphical drag-and-drop interface would be ideal, it is also
potentially very, very complex, and a set of drop-down lists would be
adequate initially. Note also that a fair amount of intelligence can be
built in. For example, when you map a table, the tool automatically asks
if you want to map tables related by PK/FK relationships.
I think the requirements for this are:
1) Graphically build a map from a DTD (XML Schema) and a database schema
2) Graphically modify existing maps. The source of the map can be a map
document or a map factory, such as MapFactory_DTD or MapFactory_Database
(not yet written).
3) Use two or more maps as input and graphically create a new map. This
is less important than the previous two requirements, as it probably
will be harder to do due to resolving conflicts where both maps map the
same thing.
>
> 6) As a subset of (5) Does anyone know if in JDBC there is some metadata
> which returns the DB & it's version (e.g. Oracle 8i or DB2 V7.1?)
See the getDatabaseProductName and getDatabaseProductVersion methods in
java.sql.DatabaseMetaData. In general, DatabaseMetaData returns almost
all the information about a database that you need to write
interoperable JDBC applications.
> 7) Here's a real tangential / future gazing point which suddenly struck me
> over the weekend........Deep Breath....
>
> I have been messing around with J2EE as part of my company's evaluation
> process. I have come to the conclusion that Entity beans are a dark plot by
> Sun & IBM to sell more powerfull servers as they are horrendous (seriously
> imagine creating an object for each row in one table where that table might
> have 500k rows...then imagine that each item has say an average of ten child
> rows held in a related table (e.g. Orders & Order lines)..........now
> visualize 500 people interacting with that...etc.etc).
>
> Reminds me of IBM's SanFrancisco Framework (& I suspect that much of EJB'es
> have come from there).
>
> However XML-DBMS creates these map objects which are then written into
> XML......If one were to be running XML-DBMS as a server process (either
> within an EJB server or without) then one could imagine calling transfer
> -tomemory (either from DBMS or from XML)............I say that because I
> think that the resultset / result idea is a better one than the lunacy
> known as the Entity Bean.
I'm not quite sure I understand the difference. In either case, aren't
you creating an awful lot of Java objects, regardless of whether they're
created by XML-DBMS or J2EE?
By the way, do you really create objects for all 500k rows at the same
time? I would have hoped that applications would process these serially.
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
For any one interested in subscribing to their mailing lists, there
are two. One is for a general discussion on XML:DB issues, the other
is for a discussion of the XUpdate language. Note that XUpdate is a
language for making changes to XML documents, not for using the data
in an XML document as a way to update a database, although it could
be
used that way.
You can find the mailing lists at:
http://www.xmldb.org/projects.html
-- Ron
--- In xml-dbms@egroups.com, andy.elvey@p... wrote:
> I just thought I'd mention this as I came across it on the
"xmlhack"
> site.
> The site says - " Kimbro Staken and Lars Martin announced the
> creation of XML:DB, an initiative for the "development of
> standardized technologies for managing the data in XML Databases".
"
>
> The URL for the article is http://www.xmlhack.com/read.php?item=828
>
> Could be worth keeping an eye on ... :-)
> -----Original Message-----
> From: Ronald Bourret [mailto:rpbourret@...]
> Sent: Wednesday, October 18, 2000 10:50 PM
> To: xml-dbms@egroups.com
> Subject: Re: [xml-dbms] Further thoughts
> Probably a good idea. Most interesting is probably any code they have
> that generates Java objects from XML Schema (the Sun Java Data Binding
> spec). I've looked at this spec before, but only today really realized
> that it does exactly what we need -- maps XML Schema to
> objects. We can
> then extend it to map to RDBMSs as needed.
>
> Enhydra is in Santa Cruz (where I live), so I might be able to talk to
> them in person.
>
OK. I am firmly of the "don't reinvent the wheel / stand on the shoulders of
giants" frame of mind.....
> I was kind of hoping you were doing this :)
>
OK I just didn't want to set about doing it just to find someone else is
doing this.
<SNIP>
Tech stuff:
I'll start simply ie. stage 1 = 1 properties file for db 1 for Parser >
Static fields.
Then file choosing / GUI
</SNIP>
> The above should be enough to start work on the UI.)
>
Ooohhh indeedy <G>.
Most of the work is within the transfer class @ the mo'.
> 3) It is not clear where the KeyGenerator implementation goes. This is
> certainly at a different level than data source information and it is
> not related to the parser. I suspect that, as 2.0 progresses, we are
> likely to separate a lot of the stuff that is currently listed under
> Options in the map file into a separate options file, and that
> KeyGenerator will go there. In the GUI, it would probably be a good
> thing to have an Options button with an Options dialog box for setting
> this sort of thing.
>
Which is why I am going to start ASAP (As **Simply** As Possible <G>.)
> As to the UI itself, I'd imagined something like the following (feel
> free to modify this as you wish).
I'll build an example Swing GUI simply for inital L&F / UI assesment (i.e.
no application code). I was thinkin in terms of a Tabbed Canvas.....
> Note that the Root Table/Column/Value stuff is a bit tricky from a UI
> standpoint. There can be multiple root tables and, for each table,
> multiple root columns/values. I'm not sure how to show this
> in the GUI.
>
See above. What I'll do is to chuck together the GUI in skeleton form & then
we can progress from there.
> As far as I can figure out, we can't use it. SQLJ is embedded SQL for
> Java. This means that you embed SQL statements in Java code,
> then run a
> preprocessor over the code to turn these into Java method calls.
>
All true so never mind.
> It does look like a nice product. As you point out, we only
> need a small
> part of this product -- mostly the graphical table mapper. I'll write
> them and see what they think, but they're a commercial product, so I
> wouldn't get my hopes up.
>
Depends on (a) how it is put to them & (b) What will be in V2.0 & when V2.0
might see the light of day.
If one could put it to them that the ability to transfer XML<>DBMS is going
to be a "killer feature" & that we only require a small part of the product
& that they could roll up a "full product" then they might well sell more of
the full product than w/o the XML-DBMS part.......
> Note that at the moment we can't write this application. The reason is
> that it is essentially a visual map factory and it can't be
> built until
> after maps have been redesigned (rewritten).
>
Yup see my point (b). However if they were to start digging into XML-DBMS
now then (a) they might be able to help improve the s/w & (b) Then they'd be
in a position to benefit by having a product ready....
> However, we can start thinking about what the UI looks like right now,
> which would probably help in the map redesign, too. Note that, while a
> completely graphical drag-and-drop interface would be ideal,
> it is also
> potentially very, very complex, and a set of drop-down lists would be
> adequate initially. Note also that a fair amount of
> intelligence can be
> built in. For example, when you map a table, the tool
> automatically asks
> if you want to map tables related by PK/FK relationships.
>
Very very very complex..........What it comes down to (& Again relates to
the DBviz product) is loading in separate DBMS mappings for each DBMS such
that info such as views, fk <> PK relationships etc can be built from the
various sys tables (i.e abstract calls such as "getPK()" or
"findRelations()" sort of things).
> I think the requirements for this are:
>
> 1) Graphically build a map from a DTD (XML Schema) and a
> database schema
> 2) Graphically modify existing maps. The source of the map
> can be a map
> document or a map factory, such as MapFactory_DTD or
> MapFactory_Database
> (not yet written).
> 3) Use two or more maps as input and graphically create a new
> map. This
> is less important than the previous two requirements, as it probably
> will be harder to do due to resolving conflicts where both
> maps map the
> same thing.
>
1 & 2 are vital where 3 is "nice to have" (at this stage).
> See the getDatabaseProductName and getDatabaseProductVersion
> methods in
> java.sql.DatabaseMetaData. In general, DatabaseMetaData returns almost
> all the information about a database that you need to write
> interoperable JDBC applications.
>
Thanks. I knew it was somewhere as we had something that did this when I was
investigating JDBC initially.
> I'm not quite sure I understand the difference. In either case, aren't
> you creating an awful lot of Java objects, regardless of
> whether they're
> created by XML-DBMS or J2EE?
>
Key diff is that or the idea of the "result set" (much like in Access
(Query)). I.e all the relationships are set out in the map objects. In
EJB'es only V2 has any real relationship mapping & even that ain't that
great. Other than that it's one row = 1 Entity bean.
> By the way, do you really create objects for all 500k rows at the same
> time? I would have hoped that applications would process
> these serially.
>
If you want to be able to interate through them using the built in find
methods then create the lot.......
There are work arounds however they are work arounds........
Adam
Dear Everyone,
I've been checking the XML Dev Con list of who's going to be speaking etc @
the San Jose Dev Con.............Of course Ron is listed but so are Brett
Mclaughlin & Jason Hunter who do lots with JDOM & Enhydra........
So Ron.....why not see if you can "run into them" there?
Adam
adam flinton wrote:
> OK. I am firmly of the "don't reinvent the wheel / stand on the shoulders of
> giants" frame of mind.....
I came from a whole family of people obsessed with reinventing wheels,
so feel free to keep beating on me about this. I did notice that Enhydra
has a XMLSchemaToJava class/package, which would probably make a good
starting point for the XML Schema map factory.
> I'll build an example Swing GUI simply for inital L&F / UI assesment (i.e.
> no application code). I was thinkin in terms of a Tabbed Canvas.....
Great! I look forward to seeing it.
Looks like I'd better get around to putting XML-DBMS on SourceForge...
> Depends on (a) how it is put to them & (b) What will be in V2.0 & when V2.0
> might see the light of day.
>
> If one could put it to them that the ability to transfer XML<>DBMS is going
> to be a "killer feature" & that we only require a small part of the product
> & that they could roll up a "full product" then they might well sell more of
> the full product than w/o the XML-DBMS part.......
I'll see what I can do. Be forewarned that I'm not much of a salesman,
so any help other people can give me here (i.e. a list of reasons these
people should give us code) is much appreciated.
> Very very very complex..........What it comes down to (& Again relates to
> the DBviz product) is loading in separate DBMS mappings for each DBMS such
> that info such as views, fk <> PK relationships etc can be built from the
> various sys tables (i.e abstract calls such as "getPK()" or
> "findRelations()" sort of things).
Note that JDBC has methods to query system tables already. They're in
the DatabaseMetaData class -- things like getTables, getColumns,
getForeignKeys, etc. (Not sure I've got the names right, but you get the
idea.) These return a result set with a predefined set of columns -- the
application just reads these one row at a time and extracts table names,
column names and types, etc.
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
> I came from a whole family of people obsessed with reinventing wheels,
> so feel free to keep beating on me about this. I did notice
> that Enhydra
> has a XMLSchemaToJava class/package, which would probably make a good
> starting point for the XML Schema map factory.
>
Yup. I have just D/L'ed the new IBM4J & Xerces for the Schema support. There
is a ton of stuff in Enhydra which might provide a short cut to what we
want. Have you had a look @ JDOM? I just investigating it @ the mo (mostly
to see what it can do for parser independance).
> Great! I look forward to seeing it.
>
OK I'll chuck it together.
> Looks like I'd better get around to putting XML-DBMS on SourceForge...
>
Looks like I'll have to get up to speed on CVS (long time no CVS....)
> I'll see what I can do. Be forewarned that I'm not much of a salesman,
> so any help other people can give me here (i.e. a list of
> reasons these
> people should give us code) is much appreciated.
>
I'll tell you what, I'll get onto the Dbviz guys if you get onto the JDOM/
Enhydra bunch.
> Note that JDBC has methods to query system tables already. They're in
> the DatabaseMetaData class -- things like getTables, getColumns,
> getForeignKeys, etc. (Not sure I've got the names right, but
> you get the
> idea.) These return a result set with a predefined set of
> columns -- the
> application just reads these one row at a time and extracts
> table names,
> column names and types, etc.
>
OK I'll dig into the JDBC JavaDocs.
Adam
Dear All,
I notice that the JAXP 1.1 Early Adopter (i.e Beta) package is available for
Download. It seems to address DOM2,Sax2 & namespaces....
Anyone tried it?
I notice the Enhydra people (ie. Lutris) are mentioned as helping........
Any impact on JDOM?
Any one with any ideas which I should use? Anyone with any views re DOM vs
JDOM?
I am tending @ the mo towards using the JAXP1.1 simply coz it's here (if
only in beta form) & it seems to address all the parser specific stuff
(DOM,Sax,NS). Also it appears (reading the X-D source & comparing with the
JAXP Doc's) that it is the path of least resistance / least work
needed.......
Anyone with any views please let me have them as otherwise it's Hi ho Hi Ho
it's off to JAXP1.1 we go........
Adam
Dear All,
Package naming.
A) if org.xml-dbms is taken, what else is there? org.xd? org.dx? I quite
like xd myself (I know there used to be a 3 letter minimum name size but
many have bust that (e.g. BT)
B) I reckon that if recompilation requirements are removed (i.e. using JAXP
/ JDOM, shoving in the JDBC driver,DB url etc @ runtime) then transfer etc
(plus the GUI) should be moved into the main body of the code (.user?
.visible? .gui?) Any ideas as to the package name?
Adam
adam flinton wrote:
> Looks like I'll have to get up to speed on CVS (long time no CVS....)
Me, too. Does anybody know of a good CVS client with a GUI that runs on
Win95? I'm command-line phobic.
> I'll tell you what, I'll get onto the Dbviz guys if you get onto the JDOM/
> Enhydra bunch.
Sounds good to me. That also splits nicely along the parts of the code
we're each working on.
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
Send Email
