Value too long for type character varying(5)


I’ve a type PartyElectronicCommunication that I remix as follows

remix type PartyElectronicCommunication {

    communicationIdentifier: string

    communicationType: string

When I try to create an instance of this type I hit the error bellow (on all tags!)

  id: 'id1', communicationUsage: 'billing',
  communicationType: 'email',
  communicationIdentifier: 'ok',
  party: {id: 'par01'}

This is the stack trace from the error:

Error: Write failed: Unable to create record for type PartyElectronicCommunication with id id1: Batch entry 0 INSERT INTO C3_2_STRUCT_PARTYEC_U (TENANT_TAG_ID,RID,COMMUNICATIONTYPE_S,COMMUNICATIONUSAGE_S,COMMUNICATIONIDENTIFIER_S,PARTY_R,COMMUNICATIONTYPE_B,COMMUNICATIONIDENTIFIER_B) VALUES (97, 'id1','email','billing','ok','par01','a00104a4-3f12-4f4d-b69c-b4a72dff4991','5ededd0a-c66e-4b73-b354-0e85977c84b2') was aborted.  Call getNextException to see the cause.
ERROR: value too long for type character varying(5)
    at new C3.client.ActionError (
    at Object.request (
    at (
    at c3Call (
    at Object._call (
    at Object.eval (eval at get (, <anonymous>:5:15)
    at <anonymous>:1:30"

Any pointers?

Overriding rules for mix and extend

Can you share the result of c3ShowType(PartyElectronicCommunication) after your provisioning?


@bachr Looking at the error message, it appears that the communicationType and communicationIdentifier fields were at one point defined as ‘boolean’ and those columns were added to the unique index. Do you have any idea how that may have happened? They are both defined as string in the base type in foundation.

The issue that it’s causing now is that we never remove columns from indexes so we generate unique values for any columns that exist in the index based on their data type. In this case, the columns are varchar(5) (to hold “true”/“false”) and our auto-generated unique values are too long.

How we fix this depends on how it happened. If it was a mistake in your configuration that was corrected, we can wipe the db (or drop the columns from the index manually). Otherwise, we will need to dig deeper.


thanks @trothwein for the explanation, it’s possible that the columns types were changed to boolean!
It’s on a dev environment so we can wipe the table, how do you suggest doing this?

@lpoirier here is a paste from the documentation

@db(unique=['communicationIdentifier,communicationType,communicationUsage,party'], index=['meta.timestamp'])
remix entity type PartyElectronicCommunication schema name 'STRUCT_PARTYEC' {
  communicationUsage: string
  communicationType: string
  communicationIdentifier: string
  isPreferred: boolean
  party: Party
 . . .


@bachr What’s the url for the environment. If the fields are boolean in one tenant/tag but string in others, this probably will remain. If it was a mistake that has been corrected, then I would suggest filing a ticket for ops to wipe the db (or advise you otherwise).