AW: [gentle-devel] AW: ALTER support

[<Gr...@mi...>]

> -----Urspr=FCngliche Nachricht-----
> Von: gop...@li...=20
> [mailto:gop...@li...] Im Auftrag=20
> von Clayton Harbour
> Gesendet: Samstag, 19. M=E4rz 2005 06:30
> An: gop...@li...
> Betreff: RE: [gentle-devel] AW: ALTER support
>=20
> I think I see a little better how this system would work. =20
> One thing that I don't like is that it seems like it would=20
> require that each property would be decorated with a guid=20
> attribute.  It also requires that there is a systems table to=20
> manage this, which is an external entity that could get out=20
> of sync (I hate to say the words but: Windows Registry).  I=20
> like the idea of using the property order to control the=20
> column order though, but I am not sure how then storing this=20
> in a table makes the system better.  Also there are some=20
> database systems (i.e.
> Oracle) that require a table to be dropped and recreated in=20
> order to change order, so both columns changing might be=20
> something we need to consider.

I didnt know this. So lets fix on saying, "never interchange columns in =
the class layout". If the system sees columns interchanged, ignore it. =
Reording wont be supported in this case, which makes diffing a lot =
easier.

> In my examples of the "property controlled revisions" all=20
> properties had changed but it is conceivable that there would=20
> be only one change (and one extra attribute, along with=20
> version `tag`) would be added to that property.  No extra=20
> meta-data would be needed.  The advantage is that the=20
> application does not rely on an external source such as the=20
> systems table for upgrade information which gives a developer=20
> more control over the database schema which in my experience=20
> is less error prone (as your application knows what is there always).

I agree.

> I am really not sure I like though is using a guid for every=20
> property in my code.  Don't get me wrong guid's are great in=20
> their place but I think here it just forces a developer to=20
> keep track of some meaningless data.

Yes, I dont like it, too. GUIDs are a technocratic, silly thing, because =
nobody can remember them. It's a lot more declarative to see the =
revisions instead of GUIDs.

> I was not proposing writing a Gentle console application to=20
> do the install just to provide a system to check/ verify=20
> versions, the console was just a simple example of an=20
> installer implementation.  It sounds like your system will do=20
> this though and just exit if it finds a version mismatch. =20
> Also the point I was trying to get across with the DBA was=20
> that they shouldn't have to do the upgrade, so I think we=20
> agree.  My point was that you, me and your DBA might not=20
> agree.  Hopefully that makes sense.

Ok, the concept of the installer would be as following:

1) Connect to database
2) Guess highest current revision number of each table
3) Upgrade tables to the highest available revision number of each class

And the concept of Gentle simply running:

1) Connect to database
2) Guess highest current revision number of each table
3) If highest available revision number missmatches the current table =
revision numbers, exit with error (throw exception)

Only forward-upgrading, no reordering of fields, field dropping if no =
data in column, table dropping if ROWCOUNT =3D 0, field size =
decrementing only if nothing gets truncated. Revision tracking with =
multiple revision-attributes, no GUIDs, no revisions-table. Is that ok?

Regards, Alex