Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stellation-res] Yet another DB abstraction idea... 
Hi,

For me, the template version is significantly more readable than the pseudo-XML
version (and frankly, I'm more familiar with XML than with SQL...).
I had to read the pseudo-XML several times to determine
a) the CONSTRAINT was not declared;
b) there was no apparent equivalent for CREATE_TRAILER.

Presumably CREATE_TRAILER would be handled via XSLT (so it's not needed in
the pseudo-XML), and therefore it's not necessary to explicitly group the parameters 
for CREATE_TRAILER (as the template version does using parentheses).
However, the very fact that CREATE_TRAILER is buried in the style sheet arguably makes the code harder to follow. I also think the much more condensed template format (6 lines, vs. 38 for the pseudo-XML) is easier to parse visually (admittedly, that may be 
a style preference from my old C++ hacking days....)
It also seems problematic that VARCHAR field lengths are specified explicitly in the pseudo-XML. I thought one goal was to abstract this kind of low-level, db-specific detail *out* of the individual db command constructs, hiding it within the 'db' abstraction. 

The template version seems like the best approach yet.

Regards,
Jim

At 10:36 AM 8/14/02 -0300, Rodolfo M. Raya wrote:

On Wed, 2002-08-14 at 05:55, Mark C. Chu-Carroll wrote:

>The template version would be:
>
>String command =
>       db.expandCommand("CREATE TABLE Properties " +
>               "($INT aid, $INT vid, $INT inheritable, $SHORTSTRING name" +
>               "$LONGSTRING value, " +
> "CONSTRAINT fk4 FOREIGN KEY (aid, vid) REFERENCES Versions(aid,vid), " + 
>               "PRIMARY KEY(aid, vid, name))$CREATE_TRAILER");
>
>
Looks a lot better than before. However, I like more the XML approach that Mariano Kamp mentioned before. 

Do you find the following pseudo-XML  difficult to read?

<create_table name="Properties">
   <field>
      <field_name>aid</field_name>
      <field_type>INTEGER</field_type>
   </field>
   <field>
      <field_name>vid</field_name>
      <field_type>INTEGER</field_type>
   </field>
   <field>
      <field_name>inheritable</field_name>
      <field_type>INTEGER</field_type>
   </field>
   <field>
      <field_name>name</field_name>
      <field_type>VARCHAR<field_length>200</field_length> </field_type>
   </field>
   <field>
      <field_name>value</field_name>
      <field_type>VARCHAR<field_length>1600</field_length> </field_type>
   </field>
   <key type="PRIMARY">
      <fields>
         <field_name>aid</field_name>
         <field_name>vid</field_name>
      </fields>
   </key>
   <key type="FOREIGN">
      <key_name>fk3</key_name>
      <references.
         <table_name>versions</table_name>
         <fields>
            <field_name>aid</field_name>
            <field_name>vid</field_name>
         </fields>
      </references>
   </key>
</create_table>
A document like this could be easily translated to fit the syntax of any DBMS via a style sheet. 

--
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email: jim.wright@xxxxxxx

Back to the top