[jira] Commented: (TORQUE-27) Need ability to pass global user-configurable platform-specific hints to templates

["CG Monroe (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/TORQUE-27?page=comments#action_12441299 ] 
            
CG Monroe commented on TORQUE-27:
---------------------------------

--- Including an e-mail thread from the torque-dev list for future reference --

Subject: Plans to add vendor-specific properties?

Greg Monroe said:

After re-reading this, a better variation occured to me.  Instead of an attribute, add an OPTION element to each main element (eg, Database, table, column, et al). This would have a key and value attribute and could be specified multiple times.

E.g.

<database....>
  <option key="mysql-db-type" value="..." />
  <option key="mssql-collate" value="..." />
  <option key="encoding" value="ISO 8859-1" />
  <table... >
    <option key=... />

This would be more generic and make it easier to read / parse.

Greg

> Thomas Fischer said:
> 
> Sounds good to me. Only I'd use the format "key1=value1,key2=value2" 
> for the sqlOptions
> 
>     Thomas
> 
> On Mon, 7 Aug 2006, Greg Monroe wrote:
> 
> > Well, here's my point of view on this.  I think this is a common 
> > enough request that we need to think about how to support stuff like 
> > this.
> > However, being a DB specifice issue, I'm not sure this should be 
> > embedded in the "core" of Torque.
> >
> > A solution I can see would be to do something similar to the 
> > following in the core code:
> >
> > 1) Modify the schema DTD to include a new attribute, sqlOptions, on 
> > all the major elements.  Define the format of this to be something 
> > that allows for a a list of key/value pairs, e.g.:
> >
> > <Table ... sqlOptions="key1, value, key1, value1">
> >
> > 2) Then add a getSqlOptions(key) method to all the matching 
> > generator classes.
> >
> > This would allow DB specific templates to be created that could have 
> > code like $table.getSqlOption(key1) in them.  Since options like 
> > this can be both DB and DB version specific, I'd see such templates 
> > being supplied as "add-ons" (using the new add-on code that I'm 
> > working on 8) ).
> >
> > So, if you need special DB features and someone has contributed an 
> > add-on set of templates, just use the Torque distro, specify and 
> > override directory, and put the add-on templates there. (And if no 
> > one has contributed one.. feel free to share.)
> >
> > This way we can semi-support DB Version X's special features, 
> > without getting the core development tied up in testing a lot of DB 
> > (and DB version) specific options support.
> >
> >> Florian Hopf said:
> >>
> >> Hi all,
> >> I'm wondering if there are any plans to include some
> vendor specific
> >> properties to Torque?
> >> Currently I'd propably need support for setting the
> character set and
> >> the storage engine in MySQL for some tables. Though I
> could modify the
> >> templates for my needs quite easily I'd appreciate a statement if 
> >> such a thing would possibly be included in Torque some time. The
> only similar
> >> reference I found is the next release section in the wiki, which 
> >> contains the suggestion to include an encoding attribute to the 
> >> database element.
> >>
> >> Kind regards
> >> Florian
> >


> Need ability to pass global user-configurable platform-specific hints to templates
> ----------------------------------------------------------------------------------
>
>                 Key: TORQUE-27
>                 URL: http://issues.apache.org/jira/browse/TORQUE-27
>             Project: Torque
>          Issue Type: Improvement
>          Components: Generator
>    Affects Versions: 3.2
>         Environment: Fedora Core 5 Linux, Sun JDK1.4.2_08.
>            Reporter: Adrian Price
>            Priority: Minor
>         Attachments: XMLOptionsTagSupport.zip, XMLOptionTagSupports-Changelog.txt
>
>
> It would be useful to provide a generic mechanism to enable the user to pass global platform-specific hints to templates. For example, for MySQL it is desirable to explicitly specify the type of table to be created, e.g., CREATE TABLE foo (...) Type = InnoDB. Such global hints could then be specified by the user through platform specific properties or property files, as in: 
> platform.properties:
> mysql.table.hint=Type = InnoDB. 
> A matching table.vm template might look something like:
> # -----------------------------------------------------------------------
> # $table.Name
> # -----------------------------------------------------------------------
> $generator.parse("$basepath/drop.vm", "", "table", $tbl)
> CREATE TABLE $table.Name
> (
> etc...
> ) $platform.getProperty('mysql.table.hint');
> Without such a capability it is necessary to hard-code the required customizations into the templates, which is a rather inflexible and inconvenient way of doing it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org