UpgradeHandler creates an unique index before fields can be initialized
0

Hi, Maybe I'm doing something wrong here. We've got a change for the Model like this.

  • All our reference entities get a field called 'Attribute'.
  • So a new field is added to all reference entities and a unique index is created for this field.
  • Because it is a new field the content is NULL of course. When DO creates the index the SQL statement fails because of duplicate values (NULL).
  • I've written an UpgradeRoutine in the OnUpgrade event which fills the newly 'Attribute' with initial values, but DO never reaches this routine because it failed when it tried to create the Index.

Regards
Paul Sinnema
Diartis AG

asked Nov 21 '10 at 03:09

Paul%20Sinnema's gravatar image

Paul Sinnema
261●88●88●96

edited Nov 22 '10 at 08:06

Alex%20Yakunin's gravatar image

Alex Yakunin
2971●4●4●12
2 Answers:
oldest newest most voted
0

Hello Paul,

I'd try splitting the model upgrade procedure into 2 phases:

  1. Add reference fields and fill them with necessary data during OnUpgrade event handler execution.
  2. Add unique index.

Hope this helps.

answered Nov 21 '10 at 05:11

Dmitri%20Maximov's gravatar image

Dmitri Maximov
2211●1●2●11

edited Nov 21 '10 at 05:59

Hi Dmitri,

Yes, that would do the trick but would mean that all our customers will have to upgrade twice too. Since indexes are not needed for the model to perform whell you could consider moving the creation of the indexes until after the 'OnUpgrade' event. That way all changes can be done in 1 upgrade.

Regards
Paul

(Nov 21 '10 at 05:49) Paul Sinnema Paul%20Sinnema's gravatar image

Paul, I understand.

We'll check whether it is possible to move index creation routine on a later stage. If it doesn't require much time, we'll implement this shortly; otherwise, we'll have to postpone the task until 4.4 is released.

(Nov 21 '10 at 06:21) Dmitri Maximov Dmitri%20Maximov's gravatar image

Fair enough, thanks for the quick responses.

(Nov 21 '10 at 06:33) Paul Sinnema Paul%20Sinnema's gravatar image
0

Possible alternatives:

  • We can allow you to modify current and extracted schema in UpgradeHandler.OnSchemaReady methods. Currently they are available, but you can access only their locked copies. So we can simply pass the unlocked ones as arguments of these methods. This will allow you to remove the index we indent to create in Upgrading stage (if this is done, it will be anyway created in Final upgrade stage due to schema difference), and thus you'll be able to modify the data as you wish there.
  • Alternatively, we can implement explicit support for "late" index creation - indexes marked as "late" will be created only on Final upgrade stage.

answered Nov 22 '10 at 07:43

Alex%20Yakunin's gravatar image

Alex Yakunin
2971●4●4●12

edited Nov 22 '10 at 07:45

I would opt for the 'late creation of indexes' option. Indexes are not really needed before that.

(Nov 24 '10 at 14:12) Paul Sinnema Paul%20Sinnema's gravatar image

We'll add support for this in v4.4.X (likely, in December), along with planned refactoring of upgrade hints API. See issue 857.

(Nov 27 '10 at 09:08) Alex Yakunin Alex%20Yakunin's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

about | faq | privacy | support | contact us

powered by OSQA