| Re: [stellation-res] Comparing abstractions |
On Thu, Aug 15, 2002 at 01:04:17PM +0000, Mark C. Chu-Carroll wrote:
>
> I did a bit of cleanup on Rodolpho's submission, and wrote a very
> quick prototype of the template mechanism. They're checked in to the
> latest version of core under repos/database. For comparative purposes, here's
> a single table implemented in each:
>
>
> Table table = new Table("Properties", _typeMap);
> table.addField("aid", "INTEGER");
> table.addField("vid", "INTEGER");
> table.addField("inheritable", "INTEGER");
> table.addField("name", "SHORTSTRING");
> table.addField("value", "LONGSTRING");
> table.addPrimaryKey(new String[] {"aid", "vid", "name"});
> table.addForeignKey("fk3", "Versions",
> new String[] { "aid", "vid" },
> new String[] { "aid", "vid" });
> System.out.println(table.generateSQL());
>
>
> String orig = "CREATE TABLE Properties (\n" +
> " aid ${INT}, \n" +
> " vid ${INT}, \n" +
> " name ${SHORTSTRING}, \n" +
> " value ${LONGSTRING}, \n" +
> " PRIMARY KEY(aid, vid, name), \n" +
> " CONSTRAINT fk3 FOREIGN KEY (aid, vid) " +
> " REFERENCESVersions(aid, vid))";
> TemplateExpander te = new TemplateExpander(typeMap);
> String result = te.expandTemplatesInString(orig);
> System.out.println("Orig: " + orig);
> System.out.println("Result: " + result);
>
> In terms of implementation, the work to convert either one into
> something we would actually use is pretty much equivalent, so
> the decision should be based solely on what we consider the
> better, clearer design.
>
> I can see advantages to each, but I lean slightly towards the templates.
> To me, it looks like we lose something by obscuring the SQL. The
> object approach is more flexible, but it's also more obscure.
>
> What are others preferences?
I'd say offer both and let the "artifact plugin" writers decide which
one is best for them.
If I would write a plugin, I would create different .sql files for the
databases we support and stick them into the plugin's .jar file. Then
when the magical "install thyself using $database" message is invoked by
the core, I would just break the sql into statements by looking at the
semicolons and "execute" each of them.
Later, when the .sql files become too hairy and tend to get out of sync,
I would worry about generating them from a single source or other subleties.
florin
--
"If it's not broken, let's fix it till it is."
41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
Attachment:
pgpsFKeD6ngS_.pgp
Description: PGP signature