Currently (v1.04), RapidApp does not call column accessors for its CRUD operations in DbicLnk Modules (i.e. Grids/Pages). It uses HashRefInflator for reads, and calls $Rs->create(\%vals) and $Row->update(\%vals) for creates and updates respectively. The reason for this design is both for performance optimization and consistency, however, it bypasses a huge chunk of DBIC model features/workflow that would be nice to be able to natively expose via RapidApp interfaces.
This issue will be used for general discussion of how to go about implementing this feature.
Questions/brainstorming/random thoughts
The biggest unknown in my mind for such a change is handling of inflated columns. The common/typical DateTime case can be programmed especially for, but what about all the other scenarios where a column accessor returns an object? Or, otherwise returns a value that doesn't fit/match the data_type of the column. RapidApp relies on the data_type of the column to know how to handle it both in terms of how it should be rendered as well as how it should be edited. If we go through accessors which don't return values normalized according to the data_type, it seems as though we'll need to add extra meta data someplace to tell RapidApp how to handle the column.
One of RapidApp's assumptions regarding the read/update cycle is that, during normal circumstances, a row should be able to be read into the interface, with all of its column values, and if re-saved without making any changes, it should not result in a change to the row on the back-end, either. Further, if using those same column values to create a new row, they should create an identical row in the database. This closed loop is able to be achieved under the current design where input/output of the value of a given column is understood by the system throughout all the layers which handle and interact with it. Can this reliably be ensured when going through accessors? Can it be so out-of-the-box, or will additional data_type metadata need to be supplied? And if no, what are all the consequences of breaking this assumption to the current system design? (the consequences might be acceptable, but this will require further investigations). But, this is also why I don't think it would be wise to attempt to turn on processing via column accessors in one place but not the other (i.e. it should not be considered safe to read rows via HashRefInflator, but then update them via calls on the Row accessors, it will have to be all or nothing)
And... if we do switch to accessors for read/update.... how do we handle create? Part of the current design holds that all operations use the same layer of abstraction. Part of why we call ->update(\%vals) is because we call ->create(\%vals)
The main challenge I see is simply the fact that DBIC result models, when used in their full glory, are designed to be exposed in code, and I'm not sure how to go about exposing them to RapidApp column interfaces without extra meta data to define the rules...
Currently (v1.04), RapidApp does not call column accessors for its CRUD operations in DbicLnk Modules (i.e. Grids/Pages). It uses
HashRefInflatorfor reads, and calls$Rs->create(\%vals)and$Row->update(\%vals)for creates and updates respectively. The reason for this design is both for performance optimization and consistency, however, it bypasses a huge chunk of DBIC model features/workflow that would be nice to be able to natively expose via RapidApp interfaces.This issue will be used for general discussion of how to go about implementing this feature.
Questions/brainstorming/random thoughts
The biggest unknown in my mind for such a change is handling of inflated columns. The common/typical DateTime case can be programmed especially for, but what about all the other scenarios where a column accessor returns an object? Or, otherwise returns a value that doesn't fit/match the data_type of the column. RapidApp relies on the
data_typeof the column to know how to handle it both in terms of how it should be rendered as well as how it should be edited. If we go through accessors which don't return values normalized according to the data_type, it seems as though we'll need to add extra meta data someplace to tell RapidApp how to handle the column.One of RapidApp's assumptions regarding the read/update cycle is that, during normal circumstances, a row should be able to be read into the interface, with all of its column values, and if re-saved without making any changes, it should not result in a change to the row on the back-end, either. Further, if using those same column values to create a new row, they should create an identical row in the database. This closed loop is able to be achieved under the current design where input/output of the value of a given column is understood by the system throughout all the layers which handle and interact with it. Can this reliably be ensured when going through accessors? Can it be so out-of-the-box, or will additional data_type metadata need to be supplied? And if no, what are all the consequences of breaking this assumption to the current system design? (the consequences might be acceptable, but this will require further investigations). But, this is also why I don't think it would be wise to attempt to turn on processing via column accessors in one place but not the other (i.e. it should not be considered safe to read rows via HashRefInflator, but then update them via calls on the Row accessors, it will have to be all or nothing)
And... if we do switch to accessors for read/update.... how do we handle create? Part of the current design holds that all operations use the same layer of abstraction. Part of why we call
->update(\%vals)is because we call->create(\%vals)The main challenge I see is simply the fact that DBIC result models, when used in their full glory, are designed to be exposed in code, and I'm not sure how to go about exposing them to RapidApp column interfaces without extra meta data to define the rules...
More to come...