Home > Archive > Smalltalk > July 2004 > GLORP versus Lens
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Michael McCloskey 2004-07-23, 3:57 am |
| Can anyone shed some light on GLORP.
I am involved with a VW 7.2 project which is using the VW Lens tool for
persistency on an Oracle database.
Questions.
1) What advantages does GLORP have over the Lens tool ?
2) Is GLORP in a stable state ?
3) Are there any tools for converting from Lens to GLORP ?
4) Is there any GLORP documentation ?
5) Will the Lens tool continue to be supported by Cincom ?
| |
| Paul McDonough 2004-07-23, 3:58 pm |
| I'm sure Alan will be along presently, so I'll just hit the high
points:
Headline: use GLORP. After a bit of porting work, you'll be very
happy.
1) I haven't used Lens enough to compare. Last I used GLORP (early
2004), it lacked some point/shoot tools one could imagine having, but
the code you write to make it work is quite intuitive. It's a true
framework, in that it masks almost all of the details you don't want
to know about; you end up just declaring which variable in which class
maps to what column in what table, and the rest is Magic.
2) stable enough to use, sure. We found a few weird, complex cases
where the code that "should" have worked didn't, or had surprising
side effects, but a workaround was always available. In every case
when we got a bit stumped, a post to the GLORP mailing list got a good
response within an hour or so. I can't recall exact table counts,
etc., but we had a VW/Oracle application with at least 50 tables of
varying size, some millions of rows. Had to tune the SQL generation
some for performance, but *not* by digging into GLORP's innards; we
were able to accomplish it by careful, experiment-driven specification
of our joins.
3) not that I know of, but Cincom engineering is actively
using/supporting GLORP (in addition to the online community), so they
might well become available.
4) yes, there's some very good documentation. www.glorp.org. You
should start here, imho: http://www.glorp.org/howglorpworks.html.
Illuminating, and brief.
5) good question ... I assume it'll get something like the standard
fade-out treatment (release <n>: tagged as obsolete; release <n+1>:
available as optional load-in; release <n+2>: gone).
Hth,
Paul
"Michael McCloskey" <maxmcclo@tig.com.au> wrote in message news:<cdq6jn$knr$1@lust.ihug.co.nz>...
> Can anyone shed some light on GLORP.
>
> I am involved with a VW 7.2 project which is using the VW Lens tool for
> persistency on an Oracle database.
>
> Questions.
> 1) What advantages does GLORP have over the Lens tool ?
> 2) Is GLORP in a stable state ?
> 3) Are there any tools for converting from Lens to GLORP ?
> 4) Is there any GLORP documentation ?
> 5) Will the Lens tool continue to be supported by Cincom ?
| |
| Alan Knight 2004-07-23, 8:56 pm |
| "Michael McCloskey" <maxmcclo@tig.com.au> wrote in news:cdq6jn$knr$1
@lust.ihug.co.nz:
> Can anyone shed some light on GLORP.
>
> I am involved with a VW 7.2 project which is using the VW Lens tool for
> persistency on an Oracle database.
>
> Questions.
> 1) What advantages does GLORP have over the Lens tool ?
> 2) Is GLORP in a stable state ?
> 3) Are there any tools for converting from Lens to GLORP ?
> 4) Is there any GLORP documentation ?
> 5) Will the Lens tool continue to be supported by Cincom ?
>
>
1) What advantages does GLORP have over the Lens tool ?
Lens was one of the very earliest mapping frameworks, and hasn't been
seriously updated in a long time. Probably the biggest architectural
problem is that it's very much designed around building client-server
applications, and doesn't deal well with server issues. Its mapping
engine also isn't very sophisticated by modern standards, and it doesn't
use some of the more advanced recent facilities. For example, Glorp can
use Oracle array-binding on inserts, which can be a very significant
performance boost in some circumstances.
So the idea is to do a thorough revision and bring Lens up to date. The
broad plan is to use Glorp as the core mapping engine for such an update.
There are also other pieces that might play into that, most notably the
Object Studio POF. The details of this, including dates, are still open.
2) Is GLORP in a stable state ?
Depends what you mean by "stable". There are people using it, and
reporting reasonably good results, but it's clearly still far away from
being production level. In particular, it is lacking in the areas of
tools, documentation, error messages, and those sorts of things. There
are also things that don't work, and important features that are missing.
Whether that counts as "stable" for you is an open question <grin>
3) Are there any tools for converting from Lens to GLORP ?
Right now there is something user-contributed, in the public repository.
It's called Glorp-Lens Translator. I haven't looked at it yet. An
important part of using Glorp as part of an update to the Object Lens
would be to have backward-compatibility with existing Lens applications
as much as possible. This is still one of those missing pieces. Any
suggestions, comments, etc. welcomed.
4) Is there any GLORP documentation ?
There are a few bits and pieces. All are accessible off of
http://www.glorp.org . The most comprehensive is the one Nevin Pratt
wrote and I did a bit of revision on. I also have a weblog, which
occasionally contains useful information, and is occasionally updated. It
has a mix of specific glorp news, general thoughts about O/R, and
miscellaneous stuff.
http://www.cincomsmalltalk.com/user...knight/blogView
5) Will the Lens tool continue to be supported by Cincom ?
Yes, but at some point it is likely to have a new version which may
require some degree of migration for existing applications. It is a
priority ot keep the intrusiveness of any migration to a minimum.
--
Alan Knight [|], Cincom Smalltalk Development
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk
"I believe that many of the systems we build today in Java would be
better built in Smalltalk and Gemstone." -- Martin Fowler, JAOO 2003
|
|
|
|
|