Compiler creates varchar(255) instead of Text for NON-UNI relation with concept of type BIGALPHANUMERIC

[jpwijbenga]

What happened

The model I have has among others the property: elmNote :: Element * Note

where Note is a BIGALPHANUMERIC datatype

Compiler created elmNote coupling table with Note column being a VarChar(255)

Note table itself was created correctly with TEXT datatype. But the coupling table could only hold 255 Chars, so errored out when inserting a longer note.

What I expected

elmNote coupling table should have Note as a Text Column instead of varchar. OR: Note should be a surrogate ID-value but then Note table has to have a 'value' column that allows longer text.

Version of ampersand that was used

v4.7.0 along with prototype framework 1.16.0 v4.6.2 generated models seem to not have this problem.

Steps to reproduce

1. Small model with Element with some UNI constructs and one elmNote relation, that has 0..N and data type BIGALPHANUMERIC Something like:

   
   elmID     :: Element * ID [UNI]
   elmNote :: Element * Note

REPRESENT ID TYPE ALPHANUMERIC REPRESENT Note TYPE BIGALPHANUMERIC

2. Create database code for this with ampersand proto.
3. See that elmNote table has two varchar columns and note table has only TEXT column.

# Screenshot / Video
![image](https://user-images.githubusercontent.com/6123882/218125302-7112b49e-8b6c-4f6c-a3ae-5cb0a92261cc.png)

# Context / Source of ampersand script

#manual-testing

Thanks, cheers!

[Michiel-s]

Together with @hanjoosten we concluded that this bug is introduced between compiler v4.2.0 and v4.3.0.

Output of database.json generated by v4.2.0 = GOOD

/* ---------------------------------------------------------- */
/* Plug elmNote                                               */
/*                                                            */
/* attributes:                                                */
/* I[Element]/\elmNote [Element*Note];elmNote [Element*Note]~ */
/* elmNote [Element*Note]                                     */
/* ---------------------------------------------------------- */
CREATE TABLE "elmNote"
     ( "Element" VARCHAR(255) NOT NULL /* OBJECT */
     , "Note" TEXT NOT NULL /* BIGALPHANUMERIC */
     , "ts_insertupdate" TIMESTAMP ON UPDATE CURRENT_TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP
     ) ENGINE     = InnoDB DEFAULT CHARACTER SET UTF8 COLLATE UTF8_BIN
     , ROW_FORMAT = DYNAMIC
;
CREATE INDEX "elmNote_0" ON "elmNote" ("Element");

Output of database.json generated by v4.3.0 = BAD

/* ---------------------------------------------------------- */
/* Plug elmNote                                               */
/*                                                            */
/* attributes:                                                */
/* I[Element]/\elmNote [Element*Note];elmNote [Element*Note]~ */
/* elmNote [Element*Note]                                     */
/* ---------------------------------------------------------- */
CREATE TABLE "elmNote"
     ( "Element" VARCHAR(255) NOT NULL /* OBJECT */
     , "Note" VARCHAR(255) NOT NULL /* OBJECT */
     , PRIMARY KEY ("Element", "Note")
     , "ts_insertupdate" TIMESTAMP ON UPDATE CURRENT_TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP
     ) ENGINE     = InnoDB DEFAULT CHARACTER SET UTF8 COLLATE UTF8_BIN
     , ROW_FORMAT = DYNAMIC
;
CREATE INDEX "elmNote_0" ON "elmNote" ("Element");
CREATE INDEX "elmNote_1" ON "elmNote" ("Note");

[Michiel-s]

Here's a script where you can see that this issue only occurs for non-uni relations with src/tgt concept as BIGALPHANUMERIC.

CONTEXT "Issue1389"

elmUniNote :: Element * Note [UNI] -- ok!
elmNote :: Element * Note -- NOT ok!

REPRESENT Note TYPE BIGALPHANUMERIC

ENDCONTEXT

The relation elmUniNote[Element*Note] [UNI] output in database.json is GOOD

/* ------------------------- */
/* Plug Element              */
/*                           */
/* attributes:               */
/* I[Element]                */
/* elmUniNote [Element*Note] */
/* ------------------------- */
CREATE TABLE "Element"
     ( "Element" VARCHAR(255) UNIQUE NOT NULL /* OBJECT */
     , "elmUniNote" TEXT DEFAULT NULL /* BIGALPHANUMERIC */ -- <-- type is TEXT. That is good
     , PRIMARY KEY ("Element")
     , "ts_insertupdate" TIMESTAMP ON UPDATE CURRENT_TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP
     ) ENGINE     = InnoDB DEFAULT CHARACTER SET UTF8 COLLATE UTF8_BIN
     , ROW_FORMAT = DYNAMIC
;

The binary table for RELATION elmNote[Element*Note] is NOT ok, as indicated in comment above.

[hanjoosten]

Zoekdomein is dus hier: https://github.com/AmpersandTarski/Ampersand/compare/Ampersand-v4.2.0...Ampersand-v4.3.0

[Michiel-s]

Thx @hanjoosten for the quick action!

[stefjoosten]

@Michiel-s, I'm having exactly the same problem. In my application, I'm using prototype framework 1.16.0. So I'm experiencing a known bug.

However, there is no prototype framework with a version > 1.16.0. So what am I supposed to do in order to get the fixed compiler? Can you publish a newer version of the prototype framework that doesn't suffer from this problem?

[stefjoosten]

This problem has been fixed in prototype framework v1.17. Use

docker pull ampersandtarski/prototype-framework:v1.17