[OPEN-ILS-DEV] Proposed modification to 1.6.0.4-1.6.1.0-upgrade-db.sql

[Soulliere, Robert]

I would lean towards washing our hands of the demo data for less pain overall.

However, I am concerned that some in the general community have not understood that this is a demo feature only in 1.6. It seemed there were a few questions on the list indicating that some were using it as a live feature and investing time in populating the tables. I asked a question a few weeks ago about how to cover the acquisitions module in version 1.6. It seems we need a big clear warning for people to enter test data only since it will be washed away in a 2.0 upgrade? Should the question be extended to the general community to get their impressions and usage of the acquisitions module or would that just complicate the debate? Or, do you think there were sufficient warning such as in the release notes?

It looked as if at least one person was trying to use it:

see:

http://libmail.georgialibraries.org/pipermail/open-ils-general/2010-November/003624.html
http://libmail.georgialibraries.org/pipermail/open-ils-general/2010-November/003626.html


Robert

-----Original Message-----
From: open-ils-dev-bounces at list.georgialibraries.org [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Mike Rylander
Sent: Tuesday, November 16, 2010 9:35 AM
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] Proposed modification to 1.6.0.4-1.6.1.0-upgrade-db.sql

On Mon, Nov 15, 2010 at 6:16 PM, Joe Atzberger <ohiocore at gmail.com> wrote:
>
>
> On Wed, Nov 10, 2010 at 9:40 AM, Mike Rylander <mrylander at gmail.com> wrote:
>>
>> On Mon, Nov 8, 2010 at 3:07 PM, Peters, Michael <MRPeters at library.in.gov>
>> wrote:
>> > Hi all,
>> >
>> > In working through the process of updating a 1.6.0.0 test server to 2.0
>> > Alpha 5 I ran across a problem with this particular upgrade.  It was
>> > impossible for me to excute line 531 of the old script:
>> >
>> > ALTER TABLE acq.purchase_order ADD COLUMN name TEXT NOT NULL;
>> >
>> > I modified line 531 to first give the name column an empty string for a
>> > name, then later added the "NOT NULL" constraint on this column via the
>> > new
>> > line 532.
>> >
>>
>> Because the acq schema is entirely non-authoritative until 2.0, I
>> suggest we simply delete any data from this table (and others that may
>> suffer similar issues) during upgrade.
>>
>> Thoughts, folks?
>>
>
> Even if the data is "premature", I don't see the point of destroying it when
> a workaround exists.

At this point we have two (essentially) diametrically opposed opinions
on the table:
 * Try to allow data entered into a demo feature to propagate into a
significantly different (in layout and interpretation) schema -- the
hope is that the data will be semantically correct and useful.
 * Wash our hands of demo data in an attempt to reduce pain down the
road caused by data was created under assumptions that don't hold
today.

Whatever consensus is arrived at is fine by me, but there will need to
be a good bit more work put into confirming old data will 1) convert
and 2) retain proper semantics if we go with the former.  At a glance,
acq.provider_contact will need similar treatment as it got a NOT NULL
field without a default as well.  There may be more to do in the
schema, and I haven't evaluated (and wouldn't be the best to do so)
the semantic changes.

Folks?

--
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com

This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message.  If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this communication
is prohibited.  If this communication was received in error, please
notify the sender by reply E-mail immediately, and delete and destroy
the original message.