From: Ken Y. Clark Sent: Thu 1/22/2004 11:11 PM
>On Tue, Jan 20, 2004 at 12:59:36PM -0000, Addison, Mark wrote:
>Sorry I'm just now responding.  I took a week off, but now I'm back.
>(And there are several SQLF bug reports needing my attention!)

No probs. (I'm snowed under at w**k at the moment so replies may be
a bit late too)

>I really pondered the best way to handle the idea of "table options."
>My first parser was for MySQL, which has the "key=value" pairs, but
>other parsers, e.g., Oracle, may single value/keywords, cf:
>I figured to just leave it a list of things, some of those things may
>be hashrefs to store key/value pairs, or they could just be words or
>phrases.  I didn't want to be too strict in the Table class about what
>I would accept.  Is that Good or Bad?

Bit of a tricky one really, its probably good and bad ;-) I think we should be
strict about how we store keywords and key/value options as they are specific
database features. That way the data can be used accross different
producers/parsers ie you don't need to know which
parser was used. Being too flexible could be break this. Of course this assumes
the options are transferable across rdbms, which would need some sort of mapping
code (trivial but tedious to write). Being consistant on the data would be a
good start! So we could either do as you say and use an array where hasrefs
give key/values, Or a hash where keywords just have a value of 1 or maybe even
seperate options() (hash) and keywords() (array) methods. Doesn't really matter
as long as we are consistant.

But I also think we need a way to add arbitary data to Tables, Fields etc. I've
been needing this recently (and I'm sure Alan has mentioned it too). The idea
being to provide a way to add extra info (probably non db specific) to the
Schema that passes through to producers that can use it if they know about it.
This would be more usefull for the non db parsers and producers. e.g. I would
like a way to add extra data to my xml schema that then passes through to my TT
code generators. Another example is the CDBI producer that creates a bunch of
lookup data about the relationships that it needs. (I've been doing it by just
adding to the Tables hash ref but thats bad!). Might be nice for parsers to
hang what ever data they parsed onto the field/table they made from it.

I was thinking maybe a another hash of data where the value is anything you
like. Producers can then search for given names, with some conventions like
prefix names with 'cdbi_' for data for that producer. Would be kewl to have them
then appear as methods on the object but would need to be carefull about

e.g. (need better names for methods!)

    cdbi_package => "Foo::Bar",
    base_class   => "Foo::DBIBase",

 $package = $table->extra_data("cdbi_package");
 $package = $table->cdbi_package;

I should have some time next week to have a go at some code.

comments, thoughts, ideas, flames, etc please....

This email (and any attachments) is intended solely for the individual(s) to whom addressed. It may contain confidential and/or legally privileged information. Any statement or opinions therein are not necessarily those of ITN unless specifically stated. Any unauthorised use, disclosure or copying is prohibited. If you have received this email in error, please notify the sender and delete it from your system. Security and reliability of the e-mail and attachments are not guaranteed. You must take full responsibility for virus checking.

Independent Television News Limited,

Registered No. 548648 England,

VAT Reg. No: GB 756 2995 81,

200 Gray's Inn Road, London WC1X 8XZ,

Telephone: 020 7833 3000.