Jan Pazdziora wrote:
On Tue, May 12, 2009 at 12:42:32PM -0400, Jeff Ortel wrote:
At build, common (common/) files are transformed by a build tool named
"chameleon" into DB
specific files. For example:
#
# cd oracle
# chameleon -s oracle -o tables/common/x.sql ../common/tables/x.sql
#
Long term, chameleon will be a Fedora project and included in Fedora
distribution.
For now, it is available on the wiki:
https://fedorahosted.org/spacewalk/wiki/PostgreSqlProject#Attachments.
I wonder what is wrong with Makefiles and sed or some other templating
/ macro packages that already are in our distribution. Inventing new
package (which will become a BuildRequires dependency) for such
a simple task seems to be unnecessary. It also makes the learning /
adoption curve more steep.
Can you provide some reasoning what the target features of the tool
should be and why they cannot be put together with existing tools?
I knew this question would come up at least once :)
And, it's a very good one.
I considered these approaches (in consult with others) and in some ways they appear to be
simpler. But, after considering the breadth and the complexity of the whole problem, I
believe a cobbled up solution would suffer from a number of limitations and would end up
being far more complex in the end. On the other hand, chameleon is already developed,
straight forward and has very few limitations.
Using a grammar based parser like chameleon means that the common schema can be expressed
using an already well know syntax. The chameleon 'common' grammar is a superset of oracle
and (some optional) postgres grammars so developers who know oracle DDL can work in the
schema as they do today. It handles differences in syntax and grammar between oracle and
postgres, as well as, any future databases (mysql?). The precision and extensibility is
unmatched by cobbled up solutions because it parses the DDL into a data model and uses a
plug-in architecture to render the DB specific DDL.
A templating approach would be my 2nd choice and has grammar independence in its favor.
But, it also has the following limitations:
- Does not handle differences in grammar.
- The common schema would have to be retrofitted with tags to replace such
as something like (or whatever):
$(TABLESPACE) and
$(USING_INDEX_TABLESPACE) and
$(NUMBER)
$(SYSDATE)
...
which would place a learning burden on developers. They would have to
learn all the tags and when/where they must/can be used.
- Some kind of tool (script) would still have to be developed/maintained.
- Would require complex tags to handle more complex differences
such as: sequence nextval syntax.
A sed/awk like approach has the following limitations:
- Does not handle differences in grammar.
- Is difficult to make context sensitive. For example, something as simple as
replacing the NUMBER oracle data type with NUMERIC for postgres would
potentially
find-and-replace in other places then in the column data type as intended.
NUMBER could appear in a CHECK constraint, a column name and inside an
number
of strings. Because the necessary precision would be difficult (maybe
impossible)
to achieve, there would be a greater risk of a non-deterministic outcome.
- Some kind of tool (script) would still have to be developed/maintained.
There is probably a clever way to combine a number of available tools to cobble up
something. But, I believe that, in the end, the result would be a very complicated and
temperamental solution that would be a nightmare to maintain.
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
