[Bug 16965] New: Add the Koha::Objects->search_related method
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Bug ID: 16965 Summary: Add the Koha::Objects->search_related method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart@bugs.koha-community.org Reporter: jonathan.druart@bugs.koha-community.org QA Contact: testopia@bugs.koha-community.org Depends on: 13019 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13019 [Bug 13019] Add base classes on which to build Koha objects -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |16961 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16961 [Bug 16961] Add the Koha::Objects->update method -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #1 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 53656 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=53656&action=edit Bug 16965: Add Koha::Objects->search_related In order to search on relations, we need this new method. Test plan: Confirm that the changes in Objects.t make sense and that the tests pass. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |16966 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16966 [Bug 16966] Koha::Patrons - Move GetBorrowersWithIssuesHistoryOlderThan to search_patrons_to_anonymise -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #2 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Shouldn't you wrap them like search does ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #3 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Marcel de Rooy from comment #2)
Shouldn't you wrap them like search does ?
I don't think so: "In list context, ->all() is called implicitly on the resultset, thus returning a list of result objects instead." https://metacpan.org/pod/DBIx::Class::ResultSet#search_related -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #4 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #3)
(In reply to Marcel de Rooy from comment #2)
Shouldn't you wrap them like search does ?
I don't think so: "In list context, ->all() is called implicitly on the resultset, thus returning a list of result objects instead." https://metacpan.org/pod/DBIx::Class::ResultSet#search_related
I mean the other search: sub search { my ( $self, $params, $attributes ) = @_; if (wantarray) { my @dbic_rows = $self->_resultset()->search($params, $attributes); return $self->_wrap(@dbic_rows); etc. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #5 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 53673 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=53673&action=edit Bug 16965: search_related returns an instanciated Koha::Objects-based object Koha::Objects->search_related should return a Koha::Objects-based object. This search_related method should follow the same rules as the search method, i.e. take into account what the caller want (scalar or list). The problem here is that we do not know (in Koha::Objects) what is the kind of objects we want to instanciate. To know it, this patch adds a get_object_class, it will return the class of the object and the resultset Koha::Object-based object. The drawback of this method is that we will have to keep it up-to-date every time we add a new Koha::Object class. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #6 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 53777 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=53777&action=edit Bug 16965: [Follow-up] Adjust get_object_class In many cases it should be possible to derive the Koha::Objects class name from the DBIx result class name in a trivial manner. If not, the DBIx result class should have a class method called koha_objects_class providing that non-trivial name, such as Libraries for Branch. Note: We are only interested in the plural form here (Koha::Objects). Test plan: Run t/db_dependent/Koha/Objects.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #7 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Jonathan: What do you think of the approach in the third patch? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #8 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Marcel de Rooy from comment #7)
Jonathan: What do you think of the approach in the third patch?
I liked the idea to have the mappings in one place, it will be easier to know which classes are already mapped. Why did you make this change: - return $object_class->_wrap(@dbic_rows); + return _wrap( $object_class, @dbic_rows ); ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com, | |martin.renvoize@ptfs-europe | |.com, tomascohen@gmail.com --- Comment #9 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Ccing Tomas, Kyle and Martin to get their opinions on this last patch. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #10 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #8)
Why did you make this change: - return $object_class->_wrap(@dbic_rows); + return _wrap( $object_class, @dbic_rows ); ?
Hmm. Somewhere in the process of testing. But we can redo it? We should not expect a Koha Object class to override a private underscored routine. So this should be exactly the same. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #11 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Marcel de Rooy from comment #10)
(In reply to Jonathan Druart from comment #8)
Why did you make this change: - return $object_class->_wrap(@dbic_rows); + return _wrap( $object_class, @dbic_rows ); ?
Hmm. Somewhere in the process of testing. But we can redo it? We should not expect a Koha Object class to override a private underscored routine. So this should be exactly the same.
Yes, that's the same, that's why I have asked why :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtj@kohaaloha.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #12 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hm, I think Marcel is offline for the next 2 weeks (according to his last goodbye on IRC) - can we move on with this somewhow? It's the next bug needed to unlock others in the dependency tree. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #13 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- To be frank, I think someone needs to go back to basics with me and explain why/what advantages Koha::Objects actually bring us above and beyond DBIx::Class.. It's feeling more and more like we're just wrapping DBIx::Class for the sake of wrapping it and not really winning anything. As such, I can't really comment here.. I use ->search_related allot within a DBIx::Class based app I've written and believe it's certainly a useful method. Beyond that, I can't comment. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #14 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Martin Renvoize from comment #13)
To be frank, I think someone needs to go back to basics with me and explain why/what advantages Koha::Objects actually bring us above and beyond DBIx::Class.. It's feeling more and more like we're just wrapping DBIx::Class for the sake of wrapping it and not really winning anything.
See Bug 17091 - Add AUTOLOAD to Koha::Objects and Bug 17226 - Improve AUTOLOAD of Koha::Object -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Marc Véron <veron@veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #53656|0 |1 is obsolete| | --- Comment #15 from Marc Véron <veron@veron.ch> --- Created attachment 56009 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56009&action=edit Bug 16965: Add Koha::Objects->search_related In order to search on relations, we need this new method. Test plan: Confirm that the changes in Objects.t make sense and that the tests pass. Tested all 3 patches together, followed test plan, result OK Signed-off-by: Marc Véron <veron@veron.ch> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Marc Véron <veron@veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #53673|0 |1 is obsolete| | --- Comment #16 from Marc Véron <veron@veron.ch> --- Created attachment 56010 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56010&action=edit Bug 16965: search_related returns an instanciated Koha::Objects-based object Koha::Objects->search_related should return a Koha::Objects-based object. This search_related method should follow the same rules as the search method, i.e. take into account what the caller want (scalar or list). The problem here is that we do not know (in Koha::Objects) what is the kind of objects we want to instanciate. To know it, this patch adds a get_object_class, it will return the class of the object and the resultset Koha::Object-based object. The drawback of this method is that we will have to keep it up-to-date every time we add a new Koha::Object class. Signed-off-by: Marc Véron <veron@veron.ch> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Marc Véron <veron@veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #53777|0 |1 is obsolete| | --- Comment #17 from Marc Véron <veron@veron.ch> --- Created attachment 56011 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56011&action=edit Bug 16965: [Follow-up] Adjust get_object_class In many cases it should be possible to derive the Koha::Objects class name from the DBIx result class name in a trivial manner. If not, the DBIx result class should have a class method called koha_objects_class providing that non-trivial name, such as Libraries for Branch. Note: We are only interested in the plural form here (Koha::Objects). Test plan: Run t/db_dependent/Koha/Objects.t Signed-off-by: Marc Véron <veron@veron.ch> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Marc Véron <veron@veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off CC| |veron@veron.ch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #56009|0 |1 is obsolete| | --- Comment #18 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 56238 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56238&action=edit Bug 16965: Add Koha::Objects->search_related In order to search on relations, we need this new method. Test plan: Confirm that the changes in Objects.t make sense and that the tests pass. Tested all 3 patches together, followed test plan, result OK Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #56010|0 |1 is obsolete| | --- Comment #19 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 56239 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56239&action=edit Bug 16965: search_related returns an instanciated Koha::Objects-based object Koha::Objects->search_related should return a Koha::Objects-based object. This search_related method should follow the same rules as the search method, i.e. take into account what the caller want (scalar or list). The problem here is that we do not know (in Koha::Objects) what is the kind of objects we want to instanciate. To know it, this patch adds a get_object_class, it will return the class of the object and the resultset Koha::Object-based object. The drawback of this method is that we will have to keep it up-to-date every time we add a new Koha::Object class. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #56011|0 |1 is obsolete| | --- Comment #20 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 56240 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56240&action=edit Bug 16965: [Follow-up] Adjust get_object_class In many cases it should be possible to derive the Koha::Objects class name from the DBIx result class name in a trivial manner. If not, the DBIx result class should have a class method called koha_objects_class providing that non-trivial name, such as Libraries for Branch. Note: We are only interested in the plural form here (Koha::Objects). Test plan: Run t/db_dependent/Koha/Objects.t Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #56238|0 |1 is obsolete| | Attachment #56239|0 |1 is obsolete| | Attachment #56240|0 |1 is obsolete| | --- Comment #21 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 56372 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56372&action=edit Bug 16965: Add Koha::Objects->search_related In order to search on relations, we need this new method. Test plan: Confirm that the changes in Objects.t make sense and that the tests pass. Tested all 3 patches together, followed test plan, result OK Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #22 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 56373 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56373&action=edit Bug 16965: search_related returns an instanciated Koha::Objects-based object Koha::Objects->search_related should return a Koha::Objects-based object. This search_related method should follow the same rules as the search method, i.e. take into account what the caller want (scalar or list). The problem here is that we do not know (in Koha::Objects) what is the kind of objects we want to instanciate. To know it, this patch adds a get_object_class, it will return the class of the object and the resultset Koha::Object-based object. The drawback of this method is that we will have to keep it up-to-date every time we add a new Koha::Object class. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #23 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 56374 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56374&action=edit Bug 16965: [Follow-up] Adjust get_object_class In many cases it should be possible to derive the Koha::Objects class name from the DBIx result class name in a trivial manner. If not, the DBIx result class should have a class method called koha_objects_class providing that non-trivial name, such as Libraries for Branch. Note: We are only interested in the plural form here (Koha::Objects). Test plan: Run t/db_dependent/Koha/Objects.t Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #24 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 56375 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56375&action=edit Bug 16965: Allow Koha::Objects->result_class -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #25 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- So.. I'm mostly OK with these patches.. but I have a related question: What's the history around the continual regeneration of dbic result classes? My general understanding of dbic over the past couple of years is that 'dbicdump' is really about allowing a migration path from a non-dbic system to a system with dbic classes. It's a one time thing, and then you should really maintain the classes and instead generate the db changes from them as opposed to the other way around. If we did this, we could happily rename our resultset and result classes and remove some of the code here that requires mapping from ::Object to ::Result classes. Just something to bare in mind. I could happily write a proof of concept for such a trivial dbic ::Result object example should people be interested in such. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #26 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Martin Renvoize from comment #25)
So.. I'm mostly OK with these patches.. but I have a related question:
What's the history around the continual regeneration of dbic result classes?
My general understanding of dbic over the past couple of years is that 'dbicdump' is really about allowing a migration path from a non-dbic system to a system with dbic classes. It's a one time thing, and then you should really maintain the classes and instead generate the db changes from them as opposed to the other way around. If we did this, we could happily rename our resultset and result classes and remove some of the code here that requires mapping from ::Object to ::Result classes.
Just something to bare in mind. I could happily write a proof of concept for such a trivial dbic ::Result object example should people be interested in such.
Yes, I think we should move forward too and obsolete kohastructure.sql etc. iirc there were problems with deploying (instead of running kohastructure for a new install), perhaps on some specific systems? Running the sql file probably was considered safer. Furthermore we would need to address how to deploy for existing installs in updatedatabase. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #27 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- This is probably a conversation for elsewhere.. I'm going to pass qa on these for now to prevent a holdup in the queue and in the knowledge that we can fix the dbic usage later fairly trivially and just clean out this code again when we have. For deployment, I actually use DBIC::DeploymentHandler myself in other apps.. it's a great tool, and would happily cope with a move from kohastructure.sql to a versioned schema scheme I believe.. It is however very dependency heavy so we may need to brew our own :( -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #56372|0 |1 is obsolete| | Attachment #56373|0 |1 is obsolete| | Attachment #56374|0 |1 is obsolete| | Attachment #56375|0 |1 is obsolete| | --- Comment #28 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 56650 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56650&action=edit [PASSED QA] Bug 16965: Add Koha::Objects->search_related In order to search on relations, we need this new method. Test plan: Confirm that the changes in Objects.t make sense and that the tests pass. Tested all 3 patches together, followed test plan, result OK Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #29 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 56651 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56651&action=edit [PASSED QA] Bug 16965: search_related returns an instanciated Koha::Objects-based object Koha::Objects->search_related should return a Koha::Objects-based object. This search_related method should follow the same rules as the search method, i.e. take into account what the caller want (scalar or list). The problem here is that we do not know (in Koha::Objects) what is the kind of objects we want to instanciate. To know it, this patch adds a get_object_class, it will return the class of the object and the resultset Koha::Object-based object. The drawback of this method is that we will have to keep it up-to-date every time we add a new Koha::Object class. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #30 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 56652 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56652&action=edit [PASSED QA] Bug 16965: [Follow-up] Adjust get_object_class In many cases it should be possible to derive the Koha::Objects class name from the DBIx result class name in a trivial manner. If not, the DBIx result class should have a class method called koha_objects_class providing that non-trivial name, such as Libraries for Branch. Note: We are only interested in the plural form here (Koha::Objects). Test plan: Run t/db_dependent/Koha/Objects.t Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #31 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 56653 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=56653&action=edit [PASSED QA] Bug 16965: Allow Koha::Objects->result_class Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 --- Comment #32 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- So much as I'm an opponent of Koha::Objects (They still just feel like boilerplate for the point of boilerplate to me), I can't find anything desperately wrong with this code. Passing QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |martin.renvoize@ptfs-europe |y.org |.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16965 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master --- Comment #33 from Kyle M Hall <kyle@bywatersolutions.com> --- Pushed to master for 16.11, thanks Jonathan, Marcel! -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org