[OPEN-ILS-DEV] IDL- fieldmapper classes
S. K. Murphy
error23 at gmail.com
Mon May 15 15:45:42 EDT 2006
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?
My other question, is, what happened to the @type in <field>; is that not
nessesary information, or will that be added back in later?
-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?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20060515/37136889/attachment.html
More information about the Open-ils-dev
mailing list