Migration?

[FCO]

Use :ver<>?

[FCO]

#7 (comment)

Has a new idea that could be used to migrations...

[Xliff]

I think migrations should be their own thing, especially since migrations are done at the Model level, not the collection one. Collection versioning is a great idea, though!

[Xliff]

Maybe best explained, Migrations are an operation between two versions of the same model. So how would that best work? Maybe have something that encapsulates models like a collection, but it is NOT a collection of models, but of conversion operations. A big problem would be naming conventions.

Say we have two versions of model A. How would a migration of A:ver<1.2> to A:ver<1.3> be named?

Is something like this possible?

migration A:from<1.2>:to<1.3> { ... }

If so, I have an idea to do this in a very clean manner.

[FCO]

no, it isn't, I think...

what about:

migration A:ver<1.3> {
   method from:ver<1.2> {...}
}

[Xliff]

Actually, that's not a bad idea. However I was hoping to use methods for individual fields. In that case, field level conversions could use another mechanism.

Try this:

# Pseudo
migration A:ver<1.3> {

  # Specific field-level conversions. Key layout is:
  #  <from_version><model><attribute> => -> $old_model, $to_model { ... }
  has %!conversions;

 has CollectionA<1.2> $!old_a;
 has CollectionA<1.3> $!new_a;

  method from:ver<1.2> {
     # Iterate over each model. 
     for $!old_a.^models Z $!new_a.^models -> ($old_model, $new_model) {
        for $new_model.^attributes -> $attr {
          with %!conversion<1.2>{$new_model}{$attr} {
             $_($old_model, $new_model)
           } else {
             # By default, we move the value from the old model to the new.
             $new_model."&{ $attr }"() = $old_model."&{ $attr }"();
           }
        }
     }
  }
}

[federico-razzoli]

Note that usually DBMSs provide non-standard SQL syntaxes for migrations, like:

• CREATE TABLE IF NOT EXISTS
• DROP TABLE IF EXISTS
• CREATE OR REPLACE TABLE
• ALTER TABLE IF EXISTS
• ALTER TABLE t ADD COLUMN IF NOT EXISTS, DROP COLUMN IF EXISTS, etc

And some databases allow to run CREATE/ALTER/DROP in transactions.

I believe that it would be nice to make use of these features, where available. For example the migration itself could have an on_conflict property that could be "ignore" (if not exists), "replace" (or replace), "fail".

[FCO]

I were wondering about migration and I think I came to something interesting...

If I have 2 versions of the same model, for example:

model Bla:ver<0.1> {
   has Int $.a is column;
}

model Bla:ver<0.2> {
   has Str $.b is column;
}

It’s relatively easy to say that it should create a column b of type string and drop the column a. The problem is try to guess what should be done with the data... if the content of be shoul be generated based on the old data on a, we have a problem, once we dropped a.

We could fix that explaining to the migration how to generate the data. The other migrations that I know manipulate the data using plain SQL. But we already have a way to manipulate data! The AST!

I don’t think it would be impossible to make something like this to generate the data for a new column:

method #`{or sub, idk} migrate:<a> {
   “String: { .a * 3 }”
}

And it would run a:

UPDATE
   my_table
SET
   b = ‘String: ‘ || a * 3

Or something that would be better for that migration (@Santec, please help me!)

Maybe something should be a bit different because it is possible to a new column on a table can use data from different tables.

_{Sent with GitHawk}

[Xliff]

@FCO:

This is why I had the %!conversions attribute.

So for something like this situation, you'd have

submethod BUILD {
  %!conversions<0.2><Bla><b> = -> { $new_model<Bla>.b = $old_model<Bla>.a };
}

So %!conversions handles all special casing at the field level.

[FCO]

Do we need the new model? Won’t we always use only the old one?

What about?

migration MySchema:ver:<0.2> {
   has Bla:ver<0.1> $.old-model1;
   has Ble:ver<0.1> $.old-model2;
   has Bla:ver<0.2> $.new-model1;
   has Ble:ver<0.2> $.new-model2;

   method Bla:<a> { “{ $!old-model1.b } & { $!old-model2.c }” }
}

And it would use the return to create the update...

_{Sent with GitHawk}

[FCO]

migration MySchema:ver:<0.2>[Bla:ver<0.2>, Ble:ver<0.2>] {
   has Bla:ver<0.1> $.model1;
   has Ble:ver<0.1> $.model2;

   method Bla:<a> { “{ $!model1.b } & { $!model2.c }” }
}

_{Sent with GitHawk}

[FCO]

migration MySchema:ver:<0.2>[Bla:ver<0.2>, Ble:ver<0.2>] {
   Bla:ver<0.2>.a = “{ Bla:ver<0.1>.b } & { Bla:ver<0.1>.c }”
}

_{Sent with GitHawk}

[FCO]

migration MySchema:ver:<0.2>[Bla:ver<0.2>, Ble:ver<0.2>] {
   method Bla:<a> { “{ Bla:ver<0.1>.b } & { Bla:ver<0.1>.c }” }
}

_{Sent with GitHawk}