Idea Details

Extend GEN Varchar-Fields to 32K - F49118

Last activity 05-29-2019 08:40 PM
KLAUS SEEGER's profile image
09-23-2014 08:10 AM


The restriction to use varchar-fields with a max length of (not fully) 4K was (as far as I know) bound to the fact that especially the supported DBMS Oracle has had a limited datatype-portfolio.

Since Oracle 12c this restriction has gone  so that even Oracle is now able to support 32k-varchar-fields.

 

I would like see this enhancement in GEN too because in other environments  the developers, dbas ... report that this restriction to the 4k boundary can be really painfull.

From a first discussion with Dan Short I know that CA would like to see that blobs should be used as a kind of workaround. But I think (and the dbas here too)  that this not a good idea.

 

So please vote for this request, thanks!


Comments

02-06-2019 02:29 PM

After engineering and product management review, we have determined that this idea will be moved to the  "wish-list" for now.

 

We recognize the value of this idea, and the addition of general CLOB support. At this time, there is not room in the foreseeable schedule to build the process and infrastructure necessary to enable this support. Development and testing of this capability will require extensive resources to complete.

 

This will be revisited once currently planned features near completion.

 

Best Regards,

 

Rob Thompson

02-05-2016 03:15 PM

As this Idea has 10 or more votes, it is being moved to Under Review and will be considered for a near future release.

01-11-2016 08:08 PM

CLOBs and BLOBs are not interchangeable as one undergoes code page translation and the other does not.  CLOBs should have been implemented at the same time as BLOBs were.

09-23-2014 06:08 PM

I agree that a BLOB would not work, as is.  The only viable way it could would be if the data stored in the BLOB was Unicode in a fixed format (e.g. UTF-8), then you could avoid code page issues.  However, the distinct lack of Unicode support from Gen on that matter rules it a non-starter.  And it's still less than effective anyway.

 

I generally agree with JCarter on this - conceptually, it's a CLOB, and should be implemented in the various DBMSes as their CLOB equivalents (varchar(max) SQL Server, LONGVARCHAR in JDBC, etc.).

 

32k shouldn't pose a barrier - but a CLOB or similar will generally allow definitions up to 2GB (same as BLOB).  And that will be a potential problem for Gen, with the new CFB limit only being 16MB.  But the precedent is there with a BLOB allowing a Unit setting of Bytes/KB/MB/GB - it should just extend to a Text field to support these larger values.

09-23-2014 02:47 PM

If the max size of a text field is changed for Oracle, it will also need to be changed for all other supported DBMS's as well because the length is set in the ERD, not in the physical database.  Also, the action diagram code uses the length set in the ERD, not in the physical database.

 

My thought on doing this would just be to allow for larger text fields in the ERD and then, on transformation, implement them as CLOBs if the length is larger than a VARCHAR (and allow a choice in the Data Structure List) or something along those lines.  From the standpoint of the action diagram and the model, the datatype would still be text and treated as text w/o having to come up with a new domain for large text fields.