For convenience/flexibility, it would be nice to have the option to set TableSpec metadata within the attrs of the existing DBIC structures (i.e. within 'add_columns()'). This wasn't done earlier because often times the result classes are generated by the Schema::Loader making this not suitable as the only API. But, later experience has shown that there are cases where it would be helpful, if available as an option.
This would be totally passive data. The system should simple look for the special named hash key 'column_tablespec' in the column and relationship info/attrs, and if found, merge it in as the base when generating the tablespec column cnf.
Additionally, the base TableSpec configs at the source/result class level could be defined similarly by setting a class attr named 'tablespec' (lowercase). For example:
Note that this would be passive data and would not require loading the actual 'TableSpec' component (and, in fact, must come before it is loaded, if at all, within the class). Now that the TableSpec component is loaded dynamically by plugins such as RapidDbic, the idea is that this passive meta data could be specified without loading the component, thus avoid the myriad of issues related to load order, etc, as we want to move away from manually loading the TableSpec component as a part of the public API. We've already done this for RapidDbic, and this feature will help to do it for other app contexts...
For convenience/flexibility, it would be nice to have the option to set TableSpec metadata within the attrs of the existing DBIC structures (i.e. within 'add_columns()'). This wasn't done earlier because often times the result classes are generated by the Schema::Loader making this not suitable as the only API. But, later experience has shown that there are cases where it would be helpful, if available as an option.
This would be totally passive data. The system should simple look for the special named hash key 'column_tablespec' in the column and relationship info/attrs, and if found, merge it in as the base when generating the tablespec column cnf.
Additionally, the base TableSpec configs at the source/result class level could be defined similarly by setting a class attr named 'tablespec' (lowercase). For example:
Note that this would be passive data and would not require loading the actual 'TableSpec' component (and, in fact, must come before it is loaded, if at all, within the class). Now that the TableSpec component is loaded dynamically by plugins such as RapidDbic, the idea is that this passive meta data could be specified without loading the component, thus avoid the myriad of issues related to load order, etc, as we want to move away from manually loading the TableSpec component as a part of the public API. We've already done this for RapidDbic, and this feature will help to do it for other app contexts...