RE: [stellation-res] SQL name length question

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: September 1, 2002 9:48 AM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: RE: [stellation-res] SQL name length question
> >
> >
> >On Sun, 2002-09-01 at 17:21, Jonathan Gossage wrote:
> >> > >For now, we're still generating the queries manually... So
> >the column
> >> > >names can't vary by database.
> >> > >
> >> > >Also, we had a summer student, named Annie Ying working on
> >Stellation.
> >> > >Annie had the very interesting observation that by using a
> >database, we
> >> > >enable extenders to write code to do things like data
> >mining directly
> >> > >against the database. It's a really interesting idea, which
> >she's using
> >> > >to try some really neat stuff. The basic idea behind what
> >she's up to is
> >> > >that there is some very interesting information in the
> >development, but
> >> > >that the standard repository interface is not well suited to doing
> >> > >things like mining that information.
> >> > >
> >> > >I think that tools that bypass the standard repository interface can
> >> > >be very interesting and valuable. (I also think that they should be
> >> > >read-only with respect to the repository tables, but that's
> >a different
> >> > >issue.) So I'd like to make sure that we keep things in a form where
> >> > >other tools can access the repository tables directly.
> >> > >
> >> > >This isn't an argument against adding an abstraction layer for SQL
> >> > >DML... But it is an argument for making sure that any such layer
> >> > >doesn't hinder the ability to access the database from outside of
> >> > >the normal repository code. (Annie's code uses an access
> >point to get
> >> > >a database object, and then uses the database object to access the
> >> > >tables.)
> >> > >
> >> > >	-Mark
> >> > >
> >>
> >> Are you going to make the assumption that other external tools will go
> >> through an access point? If so the existing code could easily
> >handle the
> >> differences in column names by simply asking the access point
> >for the name.
> >> Incidentally, not only researchers, but administrators may be
> >interested in
> >> this ability which would allow the development of custom
> >reporting to meet
> >> individual organization requirements.
> >
> >Yes, I think we should require external tools to go through the access
> >point. That way, we can make sure that external tools are forced to
> >conform to Stellation rules - like the comment I made about only reading
> >repository intrinsic tables.
> >
> >I did an experiment in the new schema for text artifacts, where instead
> >of writing queries with column names directly in the queries, it
> >references column names stored in static final string variables. I
> >consider the experiment a failure: the resulting SQL may be more robust
> >against name changes, but it's *very* hard to read. Much harder than
> >literal SQL.

I'll buy that. Once the current exercises with Windows and database support
have settled down, I would like to try my hand at doing a good database
language abstraction scheme, particularly in the context of Eclipse where I
think a really neat editor could be developed. Going this route would
probably result in a separate plugin that could be used either with or
without Stellation. It would generate SQL database independent definitions
that could then be customized at runtime for the final target database.


> >
> >On the basis of that, I really don't want to require an awkward
> >programmatic way of getting at column names. We shouldn't do it,
> >unless it's part of a carefully designed SQL abstraction mechanism
> >that's easy to use, and that makes SQL statements as easy to read
> >and understand as they are as literal strings.
> >
> >> Are you looking at providing other access for languages
> >besides Java? In
> >> this case you have another interesting set of land mines to
> >negotiate. In my
> >> organization we have just completed a C/C++ interface to part
> >of our Java
> >> based product and the exercise had its' moments.
> >
> >We definitely hope to support more than just Java.
> >
> >C and C++ are, frankly, not likely contenders. In a previous lifetime,
> >I helped work on what became VisualAge C++ 4.0, and I know all too
> >well how utterly horrific C++ parsing and processing can be. To build
> >fine-grained support for C++ that included the ability to do queries,
> >and to get the query results *right* is an incredible amount of work.
> >It's not something that I'm anxious to do. If Stellation really catches
> >on, and the Eclipse folks were to decide that they wanted to use it for
> >fine-grained support, the CDT folks are welcome to do the C/C++ language
> >component for Stellation. Personally, I won't touch it with a 10 foot
> >pole.
> >

Tell me :-(


> >The things that I see as likely contenders for language support beyond
> >Java:
> >- Javascript. I dislike Javascript, but there are some websphere folks
> > who do a lot with it, and I don't think it would be too hard to
> > support.
> >
> >- Python. Fun language, lots of users, and a reasonably easy one to tie
> > into Stellation.
> >
> >- OCaml. My personal favorite language. Given time, I would dearly like
> >  to put together an OCaml plugin for Eclipse.
> >
> >- XML Schema. There's a lot of work going on involving XML-based
> > web services, and we've had a lot of people working on it tell us how
> > useful Stellation-like capabilities would be for working on the
> > schema for those services. It would be a really challenging thing to
> > do, because it's so different. But it would be really useful,
> > and a real test of the infrastructure of the system.

How about Perl?

> >
> >	-Mark
> >
> >--
> >Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center
> >*** The Stellation project: Advanced SCM for Collaboration
> >***		http://www.eclipse.org/stellation
> >*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email:
> >markcc@xxxxxxxxxxx
> >
> >
> >_______________________________________________
> >stellation-res mailing list
> >stellation-res@xxxxxxxxxxxxxxx
> >http://dev.eclipse.org/mailman/listinfo/stellation-res