Author Topic: Best practices on extending core objects with new fields? (Read 1311 times)

JoeMurray · June 28, 2012, 06:23:09 pm

I'm wondering if there are best practices when developing extensions around whether or not one should ALTER TABLE on core objects like civicrm_uf_join or civicrm_contribution_page to add fields, or whether it is more appropriate to CREATE TABLE for a separate table with a one-to-one relation with core tables? Even in cases where custom fields are supported, like civicrm_event, there might be an argument in favour of ALTER TABLE as it avoids exposing a custom field only used programmatically from appearing in the admin UI, as well as improving performance.

While adding fields to core table can improve performance and simplify code, in other ways it is perhaps debatable whether it is a good practice, for example, handling upgradability.

I'd like to start a wiki section for best CiviCRM extension coding practices similar to http://drupal.org/developing/modules. To push the analogy, here is documentation for creating custom node types programmatically in D6 that add fields not via CCK: http://api.drupal.org/api/examples/node_example!node_example.module/6.

Maybe I've missed it, but is there a central registry handling namespaces for extensions that would be appropriate for table names? I'd like the names to be a reasonable length, similar to those of contributed Drupal modules, rather than fully qualified ones with a one to three word company name and a one to four word descriptive title of the module.

Erik Hommel · June 29, 2012, 12:09:23 am

Interesting topic...I would imagine adding fields to tables is not nice for upgradibility. Would certainly want to promote the set up of CiviCRM standards. We are about to form a cooperative of CiviCRM developers/hosters and we are thinking of some kind of certification process. Still very early steps, but the process is worthwhile.

Donald Lobo · June 29, 2012, 07:24:04 am

Ideally we should extend custom fields with at least the following two features:

1. Ability to extend the core table (i.e. alter the existing table like civicrm_contact etc) rather than create a new table. Also allow this to be an integral part of the DAO structure etc so it is seen as a core field

2. Ability to create "independent" custom tables and have "references" to other civi tables (like contacts, participants etc). This will allow folks to create more powerful modules and extensions

lobo

JoeMurray · July 03, 2012, 08:28:08 am

Thanks, Lobo.

1. Seems like we would want to rerun part of GenCode to recreate the DAO object at install and upgrade if we want new field to be an integral part of DAO structure. Seems like a good idea but not simple. Would be ideal if the extension could call the mothership svn or git repo to acquire the relevant xml for the table maybe via a generic helper extension, or perhaps have the whole xml directory included in the tarball.

Tim gave example in a recent email to API team explaining need for an hook_civicrm_upgrade of an extension that used Doctrine and Doctrine Migrations. This seems like it could be a good basis for CiviCRM's data layer, and would provide good support for integrating extensions. Is it under consideration for CiviCRM core?

2. I like this idea. As a small first step it might be good to enhance existing custom groups and fields to allow them to be reserved for use just for an extension, which would prevent them from being visible and editable by users through the admin interface.

I think it would be good to have
a) some standards around how to name custom extension fields in core tables, as well as custom tables for extensions and their fields, and
b) a central place for managing extension namespaces for tables, and fields added to core tables, etc.
This could be done as part of the extension directory infrastructure. With your approval, I'd be willing to put together a draft proposal.

Donald Lobo · July 05, 2012, 10:21:16 am

you dont need anyone's approval to work on a proposal

In general we do have the "is_reserved" concept where users/admins cannot edit things. We could extend that concept to custom groups and fields also.

lobo

CiviCRM Community Forums (archive)

News:

Author Topic: Best practices on extending core objects with new fields? (Read 1311 times)

JoeMurray

Best practices on extending core objects with new fields?

Erik Hommel

Re: Best practices on extending core objects with new fields?

Donald Lobo

Re: Best practices on extending core objects with new fields?

JoeMurray

Re: Best practices on extending core objects with new fields?

Donald Lobo

Re: Best practices on extending core objects with new fields?