This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello, I'm creating a number of entities with string fields. It seems that LightSpeed by default treats them as if they are CLOB/TEXT fields if no length is specified. This seems to be an odd choice for a default since CLOBS are used rarely when compared to limited string fields. Is there a way I can specify a default string length (say 80) such that whenever I create a new string field (or change an existing field to string field), it will restrict its length? I always forget to specify the length resulting in some failure down the line. Personally, I would have preferred to have a different field type such as CLOB (or Text) so that fields of those types are not confused with string fields. I understand that some database engines (DB2 comes to mind) have some restrictions on CLOB columns, like they cannot have a unique constraint. But this is just my preference. Thanks, Werner |
|
|
|
|
Hmm, I need to clarify what you're referring to here. The primary purpose of the designer is to represent domain models. We have the ability to translate these into database models, but the LightSpeed designer is not a database designer and therefore offers only limited support for database implementation details such as different CLOB versus VARCHAR types. Often, the domain logic doesn't require a particular length limits on a string, so we are reluctant to inject a length validation; the knock-on effect of this though is that strings do get mapped to CLOBs unless otherwise specified. Obviously, the migrations framework is focused on database implementation. So for the migrations framework, a default length for String fields and/or a separate Clob/Text type would make more sense. But those would not be well integrated with the designer. That might not be an issue for you because you're hand-writing your migrations. Is that what you're suggesting, or did you want something in the domain model designer itself? |
|
|
|
|
Hi Ivan, I was hoping Lightspeed will allow me to specify a default string length somewhere (like default policy that defines the PK type etc) and when I create a new string field (or change an existing non-string field), the validate length will automatically be populated. If I really want to store large text data in the column, I can remove it (or specify a very large number, like 4MB or 100MB). It keeps the models consistent and less error prone. I'm not sure that you can design a domain model without considering the limitations of the underlying database. If you specify that a string must be unique, one has to take into consideration that the database may not support unique constraints for CLOBS and therefore, a string without a length is simply not valid. The domain model needs to consider the fact that the database will trunacte the data if the string is too long, or worse, throw an error. Such assumption may effect the reliability and integrity of the system. If the domain model has certain performance requirements, especially when quering string fields, one must consider the impact of searching a CLOB field versus VARCHAR and/or if its length has any impact. Then there is the poor user that has to deal with these side effects. It seems that specifying a length on a string is just a good idea by default. Thanks, Werner |
|
|
|
