Any implications of changing the type of a property of a persistent class from Timestamp to String?

Question

Question

Duncan Priest · Aug 4, 2021

In a typical database, changing the type of a column from some kind of date/time to a string would require a degree of migration effort for existing values. In Caché, my suspicion is that this is not the case, and I could simply change a property definition from %Timestamp to %String (MAXLEN = "30") and recompile, without needing to worry about damaging the existing data stored for this property. Is this correct? Or would I find the existing data in this property being lost or corrupted?

Thanks in anticipation

Product version: Caché 2018.1

Discussion (3)1

Log in or sign up to continue

Julius Kavay · Aug 4, 2021

You can change the definition, the data remains as is. But you have to take care about your applications, like SQL-queries. For example a DATEPART() function could refuse to work because a property, defined as %String, may contain everything.

1 0

score 0 · Answer 1 · 2021-08-05T09:49:27-04:00

Also, any indices on such field would need to be rebuild. Indices on %String properties are expected to start with an empty space thus your queries using these indices won't return any existing (non-updated) rows.

score 1 · Answer 2 · 2021-08-05T10:22:00-04:00

Robert Cemper · Aug 5, 2021

except if ... As %String(COLLATION = "EXACT");

But rebuild of indices is still a must or good practice

1 0