Should we create a Schema class?

[FCO]

No description provided.

[FCO]

How to create different models on different files? Because the way relationship works its verry probably that a model reffer another model and vice-versa

[FCO]

Its not needed any more, once you can create relationship that will be lazily evaluated.

[Xliff]

I agree with the idea of creating a class that is a collection of models. How about we use 'Collection' as the name instead of 'Schema'? Especially since we may need to use that term somewhere else in the code.

Collections would work like this:

Collections and models in one file:

Collection AB {
  model B is table<bbb> { ... }
  model A is table<aaa> { has UInt $.id is serial; has B @.bs is relationship{ .a-id } }
  model B { has UInt $.id is serial; has UInt $.a-id is referencing{ A.id }; has A $.a is relationship{ .a-id } }
 
  has A $.a;
  has B $.b;
}

Or in multiple files:

use Model1;
use Model2;
use Model3;
 
Collection AB {
  has Model1 $.model1;
  has Model2 $.model2;
  has Model3 $.model3;
}

And objects can be versioned, ala:

use Model1:ver<0.1>;
use Model2:ver<1.3>;
use Model3:ver<1.0>;
 
Collection AB:ver<1.0> {
  has Model1 $.model1;
  has Model2 $.model2;
  has Model3 $.model3;
}

[Xliff]

The issue of getting two versions of the same Model or Collection to interoperate (migrations perhaps) is a critical issue that should be discussed if this is to be carried further.

[FCO]

what about collection instead of Collection?

[Xliff]

Fine with me, but why the change in case?

[FCO]

model is lowercase, class is lowercase... I just think collection in lowercase would be consistent...

[Altreus]

I like the way @Xliff is thinking. Whether we say collection or schema is of no odds to me, but I think I would find it clearer if it were schema. I don't see any reason why a model couldn't exist in more than one schema, after all.

In fact, I really like the idea of having a schema that is simply a subset of all the models you have in your app. That way, different parts of the app can be given different scopes.

We could go as far as to say, if you are related to a model not in your schema, you can't use it (rather than trying to look for it).

[Altreus]

I don't know that having different versions of the same model at the same time even makes sense. Taking a cue from DBIx::Class in Perl 5 land, the entire schema has a single version, since the status of all tables in the database determines whether or not they will work together.

The model classes that we create relate directly to a real-world table in a database somewhere. Only the matching versions of the models themselves are guaranteed to work with the corresponding table in the database. If we update a model and deploy the new table structure to an existing database, the old version of the model cannot (in the general case) work with this new table structure.

Ultimately, I don't think it makes any sense to support different versions of the same model in the same schema (or collection or whatever).

However, you could easily create a schema that contains an old version of the model and works on an old version of the database.

I propose the database handle be part of the instantiated schema object.

use MyApp::Schema::Model1;
use MyApp::Schema::Model2;
use MyApp::Schema::Model3;

use Red;

schema MyApp::Schema {
  has Model1 $model1;
  has Model2 $model2;
  has Model3 $model3;
}

my $*RED-SCHEMA = MyApp::Schema.new: database => database "SQLite";

And then elsewhere, you can create a schema that is compatible with an outdated database:

use MyApp::Schema::Model1:ver<0.1>;
use MyApp::Schema::Model2;
use MyApp::Schema::Model3;

use Red;

schema MyApp::Schema {
  has Model1 $model1;
  has Model2 $model2;
  has Model3 $model3;
}

# Probably export this or something
my $compatibility-schema = MyApp::Schema.new:
   database => database( "SQLite", :database<outdated.db> );

[FCO]

The idea of using different versions would be to support migrations (#15)

[FCO]

Maybe schema should be a CompUnit::Repository?

[jonathanstowe]

Yeah it wouldn't be dissimilar to a plugin loader with some additional metadata.