[Koha-devel] QA: Patches with database changes (DBix::Class)

Galen Charlton gmc at esilibrary.com
Fri Nov 29 16:55:28 CET 2013


Hi,

On Thu, Nov 28, 2013 at 4:14 AM, Marcel de Rooy <M.de.Rooy at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131129/55ee77f0/attachment.html>


More information about the Koha-devel mailing list