What is missing in my custom field vardef?

Nagy Zoltan

It is not clear from your post so maybe this step has been done but: you cannot create entries in the *_cstm tables using the Extension Vardefs framework. You have to have an entry in the "fields_meta_data" table in the database as well. It is this table that specifies that a field belongs in the *_cstm table. Studio automatically creates this entry when you create a field there. If you just use the Extension Vardefs framework then Sugar will try to add the field to the core table. However, your vardefs explicitly tell it not to do this as you have included the  entry:

$dictionary['Currency']['fields']['c_primary_key_c']['source'] = 'custom_fields';

which tells Sugar the field definition is to be found in "fields_meta_data".

In your snippet, you don't need most of the entries. They should almost all be defined within the entry in the "fields_meta_data" table.

You are able to override existing fields in the *_cstm tables by including entries in a matching Vardefs extension file (if you use Studio you will probably find it also creates one of these as well for a couple of the values that do not appear in the database table definitions).

If you are working On-Cloud and therefore are not able to explicitly use a database INSERT query to create the entry(ies) in "fields_meta_data" then you should use the manifest.php file to create the custom fields entries. Fields defined in the custom fields section of a manifest are created as items in the *_cstm table. Then you can provide a corresponding Vardefs extension file to override any items needed.

I suggest getting a local (maybe from a backup if you are On-Cloud) instance and inspecting the "fields_meta_data" table to see how it is constructed. Check it after adding a field using Studio if you are looking at a clean instance. There are some items in your snippet that are not quite correct for an entry in "fields_meta_data" - specifically the "id" value needs to be unique (globally) so is usually prefixed by the module name in case a field with the same name appears in another module.

Thanks,

JH.

You should try to avoid creating your own custom fields using the vardefs as there are several caveats:

If your installation does not already contain custom fields, you must manually create the custom table. Otherwise, the system will not recognize your field's custom vardef. This situation is outlined in the following section.
You must run a Quick Repair and Rebuild and then execute the generated SQL after the vardef is installed.
You must correctly define the properties of a vardef. If you miss any, the field may not work properly.
Your field name must end with "_c" and have the property 'source' set to 'custom_fields'. This is required as you should not modify core tables in Sugar and it is not permitted on Sugar's cloud service.
Your vardef must specify the exact indexes of the properties you want to set. For example, use: $dictionary['<module singular>']['fields']['example_c']['name'] = 'myfield_c'; instead of $dictionary['<module singular>']['fields']['example_c'] = array(['name' => 'myfield_c');. This will help prevent the system from losing any properties when loading from the extension framework.
The initial challenge when creating your own custom vardef is getting the system to recognize the vardef and generate the database field. This issue is illustrated with the example below:

This is a copy pate from sugar docs. So you CAN create it in cstm. I will have to look into the fields_meta_data and about that ID thing. Thanks

You should try to avoid creating your own custom fields using the vardefs as there are several caveats:

If your installation does not already contain custom fields, you must manually create the custom table. Otherwise, the system will not recognize your field's custom vardef. This situation is outlined in the following section.
You must run a Quick Repair and Rebuild and then execute the generated SQL after the vardef is installed.
You must correctly define the properties of a vardef. If you miss any, the field may not work properly.
Your field name must end with "_c" and have the property 'source' set to 'custom_fields'. This is required as you should not modify core tables in Sugar and it is not permitted on Sugar's cloud service.
Your vardef must specify the exact indexes of the properties you want to set. For example, use: $dictionary['<module singular>']['fields']['example_c']['name'] = 'myfield_c'; instead of $dictionary['<module singular>']['fields']['example_c'] = array(['name' => 'myfield_c');. This will help prevent the system from losing any properties when loading from the extension framework.
The initial challenge when creating your own custom vardef is getting the system to recognize the vardef and generate the database field. This issue is illustrated with the example below:

This is a copy pate from sugar docs. So you CAN create it in cstm. I will have to look into the fields_meta_data and about that ID thing. Thanks

Nagy Zoltan

You can indeed create it in cstm but the issue you have is illustrated with the line:

If your installation does not already contain custom fields, you must manually create the custom table. Otherwise, the system will not recognize your field's custom vardef.

which specifies that if you are using the extension vardefs to create custom fields (i.e. in the *_cstm table) then the custom table itself MUST exist first otherwise the field will not be built. You would need to ensure you had already built the table, with at least the id_c field, before running the QR&R. As you have not yet created any custom fields for your Currencies module, the cstm table will not exist and this is why your vardefs are not building the field for you.

The article you reference, in the developer guide, clearly gives the two ways of programmatically creating the entries in the *_cstm table. One of which is as I outlined above (use the "install_custom_fields()" method in the manifest to create the fields and the table first) and the other is the way you have tried BUT with the caveat that you need to manually create the *_cstm table yourself if this is your first field being added as the QR&R step will not CREATE *_cstm tables, only add fields to tables that exist.

Providing entries in the "fields_meta_data" table using SQL is the equivalent of using the "install_custom_fields()" method - you can use SQL to create the entries if you are On-Premise and you need to use the manifest method if you are On-Cloud. I believe that if you use the method in the manifest then you will find that Sugar actually creates the entries in "fields_meta_data" as part of the loader process.

You are nearly there with getting what you want, there is nothing wrong with your vardefs extension stuff - you just need to do the additional step to make sure the table you need is there as this is your first custom field on that module. You need to choose one of the ways to accomplish that and that depends on whether you want to (or indeed can) use SQL or a Module Loader package 

Thanks,

JH.

[EDIT]

Just for completion, and to help anyone else with this issue finding this at a later date, I should have made clearer:

If the QR&R process finds new entries in the "fields_meta_data" table then it WILL create the *_cstm table if it does not yet exist. It will create this table according to the column values supplied in the table record(s) plus any further data supplied in any extension vardefs. If the table already exists then it will of course simply add the new column(s) to the existing table

If the process finds entries in the vardefs Extensions framework then it WILL NOT create the *_cstm table but it will add or modify columns according to the supplied vardef data. This is because, by definition, the "Extension" vardefs are supposed to "Extend" existing vardefs not "Create" new ones.