Hi, On Thu, Nov 28, 2013 at 4:14 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>wrote:
How do we deal with database changes now DBIx::Class is in place?
For the short term (hopefully just the next few weeks), patches can just touch kohastructure.sql and updatedatabase.pl. When I push a patch that alters or creates a table, I will take care of running misc/devel/ update_dbix_class_files.pl to do any necessary updates to the DBIC schema classes. Patch submitters can also include changes generated by update_dbix_class_files.pl as well, although I prefer that such changes be put in a separate patch in case I need to redo them. It is a good idea for now to *not* manually change any files under Koha/Schema/Result -- instead, rely on running update_dbix_class_files.plon a clean database. If you do make a change, it should just be for supplement to the code generated by DBIx::Class::Schema::Loader, and should be placed after the following lines in a schema class file: # Created by DBIx::Class::Schema::Loader v0.07025 @ 2013-10-14 20:56:21 # DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:ZEh31EKBmURMKxDxI+H3EA One example of this is the Koha/Schema/Result/Issue.pm, where a foreign key relationship that is not yet reflected in the base SQL is noted. Can we get rid of that redundancy in short time? DBIx::Class should now
build a new database instead of kohastructure.. (How exactly btw?)
Once we are ready to switch over to using DBIx::Class to deploy the schema, loading the schema might end up being as simple as running DBIC's deploy() method. This will require some experimentation, of course. An alternative would be using DBIC's create_sql_dir method to create SQL scripts.
About the result sets, do we really need to keep track of the same things in two places there (pod line and in add_columns again)?
The POD and the code are generated by DBIx::Class::Schema::Loader at present, so the redundancy doesn't harm anything. Once we abandon kohastructure.sql, we can consider taking out the POD from the schema classes, although if we do that, it would be nice if someone were to write something that can spit out schema documentation based on the schema classes.
If a patch presents a dbrev the old way (with updatedatabase and kohastructure), should we reject it now?
No.
How does the new-style dbrev actually look like in updatedatabase (upgrade part) ? Which call should we make there to DBIx::Class or Koha::Database ?
This is still be be worked out, but it will probably look something like Koha::Database->upgrade_schema() which will be a wrapper for DBIx::Class::Schema::Versioned.
Probably calling e.g. add_column in updatedatabase and adding the column in the result class file? Or is there a nicer way to say to DBIx “update my items table” or “sync the whole db structure” (if that does not take too much time) ?
Yes -- DBIx::Class::Schema::Versioned can manage this for us. Details will need to be worked out, but essentially it will be possible to update the schema class(es), increment a version number, then use an ->upgrade() method to apply the update. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org