[OPEN-ILS-DEV] IDL- fieldmapper classes

[Mike Rylander]

I've implemented a script to take the current Fieldmapper code and
Class::DBI setup and generate an IDL XML file that loosely follows the
conventions laid out by Murphy.  I've incorporated much of what's been
brought up here, with specifics mentioned inline below.

My plan is to create a C OpenSRF app that supplies a CRUD interface to
the current DB layout in much the same way that open-ils.storage does
today.  Bill has already worked up a simple version of this
(open-ils.fetch) using libdbi (a C database driver abstraction lib) 
that does retrieval, and it's proven to be extremely fast.

Anyone interested in this thread, please check out the current cut of
the generated IDL XML at http://open-ils.org/~miker/fm_IDL.xml .

... more below ...

On 4/22/06, Mike Rylander <mrylander at gmail.com> wrote:
> On 4/22/06, Bill Erickson <billserickson at gmail.com> wrote:
> > How do you guys want to handle the class id's?  The current IDL uses the
> > Perl class names (Fieldmapper::action::survey).  There's also the DB names
> > (action.survey) and the class hints (asv).
> >

The experimental IDL uses the class hint as the @id on <class>.  This
seems like the most implementation-neutral label we have ATM.

> > The IDL will become the "fieldmapper", so I think we can safely drop that.
>

I've dropped the "Fieldmapper" prefix.

> > The class hints save space and will need to be retained in some form to
> > support existing code.  I kind of like using the DB style <schema>.<object>
> > ( action.survey) naming scheme, though, as the class name proper.  It's
> > descriptive and seemingly language neutral.
>
> Other than the fact that :: is used as a hierarchical separator for
> perl classes (and C++ and Java, too), I don't see any reason to do
> away with '::', but if you greatly prefer '.' I won't fight too hard.
> However, I don't want the assumption to be that the class name maps
> directly to a database table, though, because 1) the DB will
> necessarily define keywords that make creating useful names hard
> (user, group and table, to name a few), and I don't want to place a
> restriction on the number of parts in the class identifiers, either.
> We already have some classes with three parts even with Fieldmapper
> stripped from the front, and I tend to thing of the name as
> descriptive as a whole as opposed to <stuff>.<specific_object>.

I haven't touched this, other than namespacing the current CDBI class
name into a @fieldmapper attribute.  It's not useful outside Perl
right now, so I'm leaving the hierarchy separator alone for now.

> Right now, there are no XML namespace applied to the document.  I
> think, because of the multiple uses this will see, we should invent
> some.  We (Bill) own(s) opensrf.org, so we can use that as the base,
> and store schemas there for validation as well.  Here are some that I
> think would be useful:
>
> * base <class> definitions, <field> and <link> elements, @reltype,
> @class on <link>, etc
>   - namespace URI : http://opensrf.org/spec/IDL/base/v1
>   - should probably be the default namespace
>   - when not the default namespace, use 'osrf' as the prefix
>
> * persistance information -- the @virtual attribute, @key on <link>,
> @primary on <field> (which I don't see anymore)
>   - this isn't OpenSRF's domain, so ...
>   - namespace URI : http://open-ils.org/spec/opensrf/IDL/persistance/v1
>   - should /not/ be the default namespace
>   - use a prefix of 'oils_perist'

These, and one more
(xmlns:oils_obj="http://open-ils.org/spec/opensrf/IDL/objects/v1" for
the current FM array position and the <class> @fieldmapper attr) have
been applied.  Please take a look and tell me what you think of the
syntax and semantics.

I also added back the <links> and <fields> collection elements.  The
make me feel safe... :)

--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org