What is missing in my custom field vardef?

Hi,

I recommend to only create a basic definition and then update it after the repair

$dictionary['Currency']['fields']['c_primary_key_c']['name']='c_primary_key_c';
$dictionary['Currency']['fields']['c_primary_key_c']['vname']='LBL_C_PRIMARY_KEY_C';
$dictionary['Currency']['fields']['c_primary_key_c']['type']='int';

it's also better to name your file sugarfield_<thenameofyourfield>.php so it won't create another field after the repair (that can cause mistake with contradictory parameters) ; in my opinion, you can also avoid the _c because your field won't be considered as a custom field (not created from the studio) so it won't be store in the _cstm table but in the core one.

Fred

I ESPECIALLY want it in the custom table, that is why I defined the source (as per sugar documentation).

OK ; did you correct your type to int instead of Integer?

Yes, no luck. This is how I tried:

$dictionary['Currency']['fields']['c_primary_key_c']['name'] = 'c_primary_key_c';
$dictionary['Currency']['fields']['c_primary_key_c']['vname'] = 'Dimensions key';
$dictionary['Currency']['fields']['c_primary_key_c']['id'] = 'c_primary_key_c';
$dictionary['Currency']['fields']['c_primary_key_c']['type'] = 'int';
$dictionary['Currency']['fields']['c_primary_key_c']['dbType'] = 'int';
$dictionary['Currency']['fields']['c_primary_key_c']['source'] = 'custom_fields';
$dictionary['Currency']['fields']['c_primary_key_c']['len'] = 10;
$dictionary['Currency']['fields']['c_primary_key_c']['size'] = 10;
$dictionary['Currency']['fields']['c_primary_key_c']['unified_search'] = false;

I tried on my instance and with your full definition it is not working.

If you just put the 3 lines and accept the field to be created in the core table, it works.

2 possibilities

- the currency module canno't manage a _cstm extension table

- the table must exists in order to perform the repair (I got error message in the sugarcrm.log with your definition)

It is paramount to put into the _cstm table. SugarCRM itself announced us in a in-house webinar (they visited our company) that sometimes they upgrade core table structure by copy, drop table, create, copy from clone back, instead of alter table. And in general is bad practice to put custom fields into core table. One of the reasons why I am rewriting our entire codebase is to rip out the custom fields from the core table. Should I go to sugar portal and contact them?

Silly question maybe, but I'm curious why you need to add a currency field as an integer?
I'm also told to add all custom fields via Studio to ensure upgrade safe methods

This is not a currency field it is A field in currency module. And it is the synchronization key from our software with which CRM communicates. If the field is 0 means the currency rates have not yet been updates, if the field is 123 it means it corresponds with the record ID = 123 on our other software

as far as we created fields through codes (so within the core table instead of the cstm table), we never experimented upgrade issues.

Furthermore, this is easier to manage with source versioning or to package it for a module loader deployment.

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.