From: Volkan YAZICI
Subject: [ann] SST (SQL Schema Transformer) Project
Date: 
Message-ID: <e5964dfb-aa63-4938-916e-98c9018f4e14@25g2000hsx.googlegroups.com>
Hi,

I've just released the first public release of SST[1] (SQL Schema
Transformer) which we have been using in production since a couple of
months. SST is a Common Lisp program that transforms an s-expression
based database schema format medium into appropriate SQL commands for
specified RDBMS. SST is capable of

    * Dividing produced queries into logically separate (schemas,
tables, primary keys, foreign keys, indexes) files.
    * Customized (and extendable) identifier formatters. (You can
adopt a naming scheme you prefer to name tables, indexes, etc.)
    * FOREIGN KEY data type mismatch detection.
    * Invalid FOREIGN KEY reference detection.
    * Missing index detection for ON DELETE/UPDATE CASCADE references.
    * FOREIGN KEY reference auto-completion. (You don't need to supply
column of the referenced table. SST infers it for you.)

See README[2] file further details.


Regards.

[1] http://www.cliki.net/sst
[2] http://www.students.itu.edu.tr/~yazicivo/files/sst.README.txt

From: Andy Chambers
Subject: Re: SST (SQL Schema Transformer) Project
Date: 
Message-ID: <d5c86f48-6c80-4f58-980d-854237b731d4@y38g2000hsy.googlegroups.com>
On 24 Sep, 15:52, Volkan YAZICI <·············@gmail.com> wrote:
> Hi,
>
> I've just released the first public release of SST[1] (SQL Schema
> Transformer) which we have been using in production since a couple of
> months. SST is a Common Lisp program that transforms an s-expression
> based database schema format medium into appropriate SQL commands for
> specified RDBMS. SST is capable of
>
>     * Dividing produced queries into logically separate (schemas,
> tables, primary keys, foreign keys, indexes) files.
>     * Customized (and extendable) identifier formatters. (You can
> adopt a naming scheme you prefer to name tables, indexes, etc.)
>     * FOREIGN KEY data type mismatch detection.
>     * Invalid FOREIGN KEY reference detection.
>     * Missing index detection for ON DELETE/UPDATE CASCADE references.
>     * FOREIGN KEY reference auto-completion. (You don't need to supply
> column of the referenced table. SST infers it for you.)

Looks interesting.

What's the reasoning behind using strings instead of symbols for
database identifiers (tablenames/columns etc).  Isn't the set of
characters allowed in a symbol a superset of the set of characters
allowed in a database identifier?

Also, why is produce-sql-output a macro?  Wouldn't it be just as easy
to make it a function?

--
Andy
From: Volkan YAZICI
Subject: Re: SST (SQL Schema Transformer) Project
Date: 
Message-ID: <8ac6b00d-08bb-4c65-a148-4bc054942c78@m45g2000hsb.googlegroups.com>
On Sep 25, 3:48 pm, Andy Chambers <··············@googlemail.com>
wrote:
> Looks interesting.

Thanks for spending time to check it out.

> What's the reasoning behind using strings instead of symbols for
> database identifiers (tablenames/columns etc). Isn't the set of
> characters allowed in a symbol a superset of the set of characters
> allowed in a database identifier?

One'll need to type "|FoO|" for case sensitive identifiers (see :QUOTE
for :IDENTIFIER-CASE) and it will also require extra SYMBOL-NAME calls
in the code.

> Also, why is produce-sql-output a macro?  Wouldn't it be just as easy
> to make it a function?

Hrm... You have a point. Actually, I had started the design with
another idea in mind (was planning to implement some sort of parser
similar to meta, but on the halfway I realized that I cannot
incrementally the produce code for each operation -- consider
extracting a primary key column for a foreign key defined earlier than
the referenced table), but things changed so much on the way. If I
don't miss a point, your suggestion is quite feasible -- I'll try to
implement it in the next release.


Regards.
From: Volkan YAZICI
Subject: Re: SST (SQL Schema Transformer) Project
Date: 
Message-ID: <b61fcd6f-df5f-44f6-a8b5-90602dade094@s50g2000hsb.googlegroups.com>
Volkan YAZICI <·············@gmail.com> wrote:
> Andy Chambers <··············@googlemail.com> wrote:
> > Also, why is produce-sql-output a macro?  Wouldn't it be just as easy
> > to make it a function?
>
> Hrm... You have a point. Actually, I had started the design with
> another idea in mind (was planning to implement some sort of parser
> similar to meta, but on the halfway I realized that I cannot
> incrementally the produce code for each operation -- consider
> extracting a primary key column for a foreign key defined earlier than
> the referenced table), but things changed so much on the way. If I
> don't miss a point, your suggestion is quite feasible -- I'll try to
> implement it in the next release.

Done. SST 0.0.2 is publicly available.


Regards.