RE: PropertySet 1.0.x to 1.2.x conversion

Yup, it's a bummer you got bit by these things. Fortunately the project
has matured quite a bit and you most likely won't hit these snags
anymore, since you are no longer an "early adopter". 

Wrt to the key->keyvalue change... My bad. I should have documented it.
It was a worthy change though, otherwise we would have had everyone and
their mother complaining that the schema was "broken" -- all of which
wouldn't know how to change orion-ejb.xml or equivalent. But still,
there is no excuse for me not documenting it better.

Patrick

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf
Of
> Colin Sampaleanu
> Sent: Friday, February 06, 2004 5:34 PM
> To: [email protected]
> Subject: Re: [Opensymphony-developers] PropertySet 1.0.x to 1.2.x
> conversion
> 
> Well, this is a lesson to me that you have to have treat projects with
> an attached db schema (and I guess storing stuff out to xml would
> probably be pretty equivalent) much differently from normal libs don't
> do any external storage, in terms of trying to make a decision whether
> to use them or not.
> 
> With a refactoring IDE like Eclipse or IDEA, it's generally trivial to
> stay up to date with changing open source libs, and you reap some
> benefits usually, as you save some serious coding if no other library
> has those features. But if there's a database involved, that
> fundamentally changes the picture, as it's hard to be very agile with
> it. The legacy data has to move over, and that's painful to do in
terms
> of the actual coding, and painful in terms of logistics like
scheduling
> it.
> 
> Live and learn...
> 
> 
> 
> Hani Suleiman wrote:
> 
> > Yeah, I winced when you first mentioned that you're moving from 1.0.
> > The most painful aspect I'd imagine was 1.x to 2.x, after that (and
> > from now on) hopefully it'll be smooth and well documented,
especially
> > give that there are quite a few deployments in production
environments
> > using osworkflow.
> >
> > On Feb 6, 2004, at 7:48 PM, Colin Sampaleanu wrote:
> >
> >> I actualy thought of that being the reason, after I posted the
> >> message. It's probably an ok reason, had the change been
documented.
> >>
> >> Once I am completely finished and have working code, I am going to
> >> update the wiki to better describe the upgrade from OsWorkflow 1.0
to
> >> 2.6, including the 3 related libs. Generally it has been a hellish
> >> journey:
> >>
> >> OsWorkflow:
> >> - tables changed in 3-4 steps, described, but not completely or
> >> accurately.
> >> - java apis and usage changed, touching a bunch of code (mostly
from
> >> the FunctionProvider interface changing, but it's an error prone
> >> upgrade, plus some semantic differences here and there).
> >> -  workflow definition changed, with clear procedure, but almost
> >> every other line needing touching
> >> OsUser:
> >> - we were using a custom provider, so work was less than it might
> >> have been. Update provider for package movement. change config
files
> >> OsCore/Propertyset:
> >> - handle undocumented changes in sequence tables
> >> - handle undocumented changes
> >> - handle changes in config and usage
> >>
> >> Btw, don't get me wrong. I'm not making these comments to the
extent
> >> that I am trying to say I 'expected' that things had been
documented
> >> better. In the end all that you can expect of an open source
project
> >> is exactly what the developers decide to give you. If I am a bit
> >> frustrated now it's because I either should either not have used
the
> >> stuff in the first place as it was too raw, or tried to upgrade
more
> >> often as stuff got released (not much of a possiblity due to some
> >> constraints here, and might have added up to more work anyways), or
> >> made sure that now more time was allocated to this upgrade, in the
> >> middle of an already way too tight schedule.
> >>
> >> Regards,
> >> Colin
> >>
> >> Hani Suleiman wrote:
> >>
> >>> Yes, I agree absolutely.
> >>>
> >>> This was back in the day when Pat was young and innocent and knew
> >>> next to nothing about backward compatibility. His reason for
> >>> changing this was that some db's didn't allow a column of name
key.
> >>>
> >>> I'm sorry you got bit by this, but rest assured these sorts of
> >>> arbitrary changes don't happen anymore without very very good
reason
> >>> (which hopefully makes them a bit less arbitrary!)
> >>>
> >>> On Feb 6, 2004, at 6:56 PM, Colin Sampaleanu wrote:
> >>>
> >>>> Actually that's not true. For some unknown reason, the entry's
> >>>> 'key' field has changed the matching db column name from 'key' to
> >>>> 'keyvalue'. This seems to be very arbitrary and annoying (unless
> >>>> I'm missing something), as the code itself still seems to be the
> >>>> same, but it added another schema piece I have to migrate.
> >>>>
> >>>> from oscore roughly 1.0, PropertyEntryEJB.java:
> >>>>    /**
> >>>>     * @ejb:persistent-field
> >>>>     * @ejb:interface-method
> >>>>     * @jboss:column-name name="key"
> >>>>     * @weblogic:dbms-column key
> >>>>     * @orion:persistence persistence-name="key"
> >>>>     * @ejb:persistence column="KEY"
> >>>>     */
> >>>>    public abstract String getKey();
> >>>>
> >>>> from propertyset 1.2, PropertyEntryEJB.java:
> >>>>    /**
> >>>>     * @ejb.interface-method
> >>>>     * @ejb.persistence column-name="keyvalue"
> >>>>     */
> >>>>    public abstract String getKey();
> >>>>
> >>>> Regards,
> >>>> Colin
> >>>>
> >>>>
> >>>> Hani Suleiman wrote:
> >>>>
> >>>>> Yeah, none of the schemas have changed.
> >>>>>
> >>>>> Colin Sampaleanu said:
> >>>>>
> >>>>>> Colin Sampaleanu wrote:
> >>>>>>
> >>>>>>
> >>>>>>> I am currently converting an app from OSWorkflow 1.0 to 2.6.
The
> DB
> >>>>>>> conversion was relatively straightforward (although less than
> >>>>>>> enjoyable) since it is for the most part documented. I am
actually
> >>>>>>> going to fix up a few glitches in the docs on the wiki and
> >>>>>>> contribute
> >>>>>>> a program which does the conversion.
> >>>>>>>
> >>>>>>> However since OSWorkflow depends on PropertySet, I now seem to
> have
> >>>>>>> come to the nasty part. Is there any documentation on
converting
> an
> >>>>>>> existing schema/data from PropertySet 1.0.x (seems like
> >>>>>>> OsWorkflow 1.0
> >>>>>>> uses PropertySet 1.0.0) to version 1.2 (which is what
OsWorkflow
> >>>>>>> 2.6
> >>>>>>> seems to use). Looks like the many tables used before, one for
> each
> >>>>>>> entity type, have been consolidated into the one entry table.
I am
> >>>>>>> just starting this conversion, and will of course figure
things
> out
> >>>>>>> from the source if needed, but if there is any existing
document
> or
> >>>>>>> email that already spells it out, it would be much
appreciated...
> >>>>>>>
> >>>>>>>
> >>>>>> Never mind. I did not realize that the different impls. of
> >>>>>> PropertySet
> >>>>>> used different schemas. I was comparing the PropertySet 1.0.0
EJB
> >>>>>> impl's
> >>>>>> schema to the PropertySet 1.2 JDBC impl's schema. Looks like
the
> EJB
> >>>>>> schema has not changed...
> >>>>>>
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn