Bug #19813 for Handel: Hard coded column names prevent effective subclassing

Sat Jun 10 05:20:15 2006 Guest - Ticket created

Subject:

Hard coded column names prevent effective subclassing

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.

Sun Jun 18 12:04:13 2006 claco [...] cpan.org - Taken

Sun Jun 18 12:06:17 2006 claco [...] cpan.org - Correspondence added

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. :-)

Sun Jun 18 12:06:18 2006 The RT System itself - Status changed from 'new' to 'open'

Tue Jun 20 14:09:35 2006 claco [...] cpan.org - Correspondence added

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.

Sat Sep 23 19:10:27 2006 claco [...] cpan.org - Correspondence added

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.

Sat Sep 23 19:10:29 2006 claco [...] cpan.org - Status changed from 'open' to 'resolved'