[OPEN-ILS-DEV] IDL- fieldmapper classes

[Mike Rylander]

On 5/15/06, S. K. Murphy <error23 at gmail.com> wrote:
> So, I have a couple of comments/questions:  First off, yes, keeping the
> <links> and <fields> containers is a good idea, same for keeping the
> <field>s that might be covered in <link>s, so I'm glad that all came back.
> I have a question, and by question, I mean request for information.  Those
> links up there don't seem to be working for me right now, so can I have some
> more information about the oils_persist and oils_obj namespaces?
> Specifically, and this is just a matter of curiousity, what does the
> @oils_persist:primary within the <fields> tag mean?

http://open-ils.org/~miker/fm_IDL.xml  <-- That should be working, or,
it does from my house. If that's the one you can't get to then I'll
email the IDL xml directly to you, but it's kinda big. ;)

The @oils_persist:primary attr identifies the field(s) that make up
the primary key, or identity, of the class.  On further contemplation,
perhaps that should be spelled @identity without a namespace.  It
lives on the <fields> tag because there can only be one definition of
"identity" for a class, so it needs to be on a non-repeating tag.

The oils_persist and oils_obj namespaces are simply used to keep
OpenILS information that we want embedded inside the IDL from
polluting the main OpenSRF IDL namespace.  OpenSRF proper doesn't care
about OpenILS info, so it shouldn't exist in the default namespace.
... once you see the example IDL I think it will make sense.

>
> My other question, is, what happened to the @type in <field>; is that not
> nessesary information, or will that be added back in later?
>

It's still very useful, but I don't have any way of generating it from
/just/ the existing Fieldmapper code.  I'm pulling that information
out of the database in the experimental C code, but I'm unsure how
I'll generate that from Perl without connecting to a live database (I
don't now when generating the XML).

> -Murph
>
>
> On 5/7/06, Mike Rylander <mrylander at gmail.com> wrote:
> > 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
> >
>
>
>
> --
>
> "But can you imagine if we all start demanding?"


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