Extended attributes, making them generic ?
Hi Koha-devel, We've a customer that is asking for new -probably specific- fields in the subscription. For example, what they called: "subscription origin". I was wondering if a good way to do that would be to transform our "borrowers attributes" to become "extended attributes". Those extended attributes being managed as patron, subscription, acquisition,... attributes. What it means : * changing the table name ! (now, it's borrowers_attributes and borrowers_attribute_types) * removing foreign keys to borrowers table. * add a field "scope" (or similar name), that would be borrower, subscription, acquisition, ... * update all the code to handle this "scope" field. For example, borrower_attributes.borrowernumber would become "extended_attributes.externalid", pointing to the borrowernumber, the subscriptionid or the ordernumber. What do you think of the idea ? (I don't promize that, even if everybody says it's a wonderful idea, we will do it) -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper
Hi, On Tue, Sep 17, 2013 at 7:03 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
I was wondering if a good way to do that would be to transform our "borrowers attributes" to become "extended attributes". Those extended attributes being managed as patron, subscription, acquisition,... attributes.
I think a generalized attribute system would be useful. Besides the ones you've listed, I can immediately see uses for bib-level attributes.
What it means : * changing the table name ! (now, it's borrowers_attributes and borrowers_attribute_types) * removing foreign keys to borrowers table.
However, I don't think it should be implemented in such a way that it drops foreign key constraints, of which we need more in Koha, not fewer. Instead, I propose that each class we want to give extended attributes to get a separate table. Each attribute table would have the same structure, allowing for code (and DBIC classes) to be generic, e.g., subscription_attributes: subscriptionid int(11) code varchar(10) -> attribute_types.code attribute varchar(255) aqorder_attributes ordernumber init(11) code varchar(10) -> attribute_types.code attribute varchar(255) ... and so on. Note that the proposed attribute_types table (which could be created by renaming borrower_attribute_types) could be shared 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
On Tue, Sep 17, 2013 at 07:41:04AM -0700, Galen Charlton wrote:
What it means : * changing the table name ! (now, it's borrowers_attributes and borrowers_attribute_types) * removing foreign keys to borrowers table.
However, I don't think it should be implemented in such a way that it drops foreign key constraints, of which we need more in Koha, not fewer. Instead, I propose that each class we want to give extended attributes to get a separate table.
We are heavily using extended patron attributes (about 10 for each borrower) and I also think that different tables is better solution since droping referential integrity is never good idea (IMHO). Droping it would also mean some sort of performance penalty (if we don't create additional indexes) when joining with "master" tables (borrowers etc in future). But real justification for one single extended attributes might be that we want to somehow generate reports which access more than one type of extended attributes. I can't think of any example of such use-case, so that's why I do prefer separate smaller tables for each extended attribute type (which, as side-effect might be beneficial for performance and we can keep referential integrity on them). -- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
Hi Paul, I already implemented this feature. Bug 10855 allows to have additional fields for subscriptions. The new fields are displayed on the add/edit/show views and can be searched on the serial search page. That can be extended to others tables. Jonathan 2013/9/17 Paul Poulain <paul.poulain@biblibre.com>:
Hi Koha-devel,
We've a customer that is asking for new -probably specific- fields in the subscription. For example, what they called: "subscription origin".
I was wondering if a good way to do that would be to transform our "borrowers attributes" to become "extended attributes". Those extended attributes being managed as patron, subscription, acquisition,... attributes.
What it means : * changing the table name ! (now, it's borrowers_attributes and borrowers_attribute_types) * removing foreign keys to borrowers table. * add a field "scope" (or similar name), that would be borrower, subscription, acquisition, ... * update all the code to handle this "scope" field. For example, borrower_attributes.borrowernumber would become "extended_attributes.externalid", pointing to the borrowernumber, the subscriptionid or the ordernumber.
What do you think of the idea ? (I don't promize that, even if everybody says it's a wonderful idea, we will do it) -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (4)
-
Dobrica Pavlinusic -
Galen Charlton -
Jonathan Druart -
Paul Poulain