Antw: Re: revised gda-xml-query.dtd
- From: "Gerhard Dieringer" <DieringG eba-haus de>
- To: <malerba linuxave net>
- Cc: <gnome-db-list gnome org>
- Subject: Antw: Re: revised gda-xml-query.dtd
- Date: Tue, 18 Jul 2000 10:15:00 +0200
You wrote:
> ...
> <!ELEMENT chain (sources, joins*, values, qual?)>
> <!ATTLIST chain
> type (union|unionall|intersect|minus) #REQUIRED>
>
> ----> I'll have to think a bit more about this, since I first thought it would
> be better to chain entire queries.
> ...
You are right. When I tried to implement it in your gda-xml-query.c (you got me revised version?), I found that it's not a good solution for union, ...
But until now I didn't find a better one.
> ...
> <!ELEMENT func (field|const|func)*>
> <!ATTLIST func
> name NMTOKEN #REQUIRED
> alias NMTOKEN #IMPLIED>
>
> ---------> Add the aggregate attibut as you mentionned it. It was a better idea
> than the aggregate element!
Done.
> ...
> <!ELEMENT fielddef EMPTY>
> <!ATTLIST fielddef
> id ID #IMPLIED
> name NMTOKEN #REQUIRED
> type (int|float|varchar|fixedchar|datetime) #REQUIRED
> size CDATA #IMPLIED
> notnull (yes|nos) "no">
>
> --------> The type is too much limited like this, we should put a NMTOKEN
> instead. But I don't know how to care about data types which require one or
> more arguments (such as varchar(30) or varchar(50)). Any idea?
> ..
the size was intended for that: varchar(30): type="varchar" size="30"
We could add another attribute 'scale' and use the following mapping:
type="float" size="10" scale="5"
Oracle: NUMBER(10,5)
PostgreSQL: FLOAT8, or FLOAT4 if size < 6, ignoring scale
other DBMS: I only known other DBMS by name and can't say anything about them.
My idea of limiting the type was to allow only types, that all (usable) DBMSs support.
> ...
> <!ELEMENT sequence EMPTY>
> <ATTLIST sequence
> name NMTOKEN #REQUIRED
> start CDATA #IMPLIED
> inc CDATA #IMPLIED>
>
> ---------> I wonder if it is enough to define sequences for ALL the DBMS (I
> know that postgres allow the user to set more attributes, what about the
> others). We have to think more about it :)
It was only a first suggestion, but with the same intention as above.
Gerhard
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]