Skip Menu |
 

This queue is for tickets about the Handel CPAN distribution.

Report information
The Basics
Id: 19813
Status: resolved
Priority: 0/
Queue: Handel

People
Owner: claco [...] cpan.org
Requestors: tkp [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.99_02
Fixed in: (no value)



Subject: Hard coded column names prevent effective subclassing
Download (untitled) / with headers
text/plain 476b
Throughout the Handel code base there are various hard coded column names (specifically the PK/FKs for each table) which make complete subclassing rather difficult. For example, most of the methods in Handel::Order look for an 'id' column whilst in my schema, all my PK columns are all named after the table in which they live, so My::Schema::Order has a PK of 'order_id'. This doesn't play nicely with a subclassed Handel::Order in which I have told it to use my own Schema.
Download (untitled) / with headers
text/plain 226b
Already in the Todo: - better abstract column names - better abstract id column types I think it's just a matter of inspecting the schema source primary columns, and the item_relationship to get the field names. :-)
Download (untitled) / with headers
text/plain 953b
On Sat Jun 10 05:20:15 2006, guest wrote: Show quoted text
> Throughout the Handel code base there are various hard coded column > names (specifically the PK/FKs for each table) which make complete > subclassing rather difficult. > > For example, most of the methods in Handel::Order look for an 'id' > column whilst in my schema, all my PK columns are all named after the > table in which they live, so My::Schema::Order has a PK of 'order_id'. > This doesn't play nicely with a subclassed Handel::Order in which I have > told it to use my own Schema.
And I think PK/FKs are where this will stop. I would not be inclined to do anything with the following: sub save { shift->type(CART_TYPE_SAVED) }; One can always a) subclass save(), or b) add type() to their subclass if there is no field called "type" in the current schema. But I do agree otherwise, that there's no need to reference PK/FK field names directly if we can grep them from the schema source itself.
Download (untitled) / with headers
text/plain 254b
This is somewhat resolved in 0.99_14, which should be on cpan shortly. I've tried to use primary keys instead of specific column names, and copy columns using storage->columns and has_column. The remaining uses should be easily fixed during subclassing.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.