For now automatic type substitution is not yet available. But you can do that with few lines of code in the template file (.vm file). You will have to change the Java type in the "imports list" and in each Java field definition. *1) For the imports :* ( replace "java.util.Date" by "java.time.LocalDate" ) --- #set($imports = $java.imports($entity) ) $fn.replaceInList($imports, "java.util.Date", "java.time.LocalDate") #foreach( $import in $imports ) import $import; #end --- *2) For the Java fields : * ( replace "Date" by "LocalDate" ) --- #foreach( $field in $dataFields ) #set($fieldType = $field.type ) #if($fieldType == "Date")#set($fieldType = "LocalDate")#end private $fieldType $field.formattedName(12); #end --- NB : version 3.3.0 is required (for $fn.replaceInList(..) )

Hi, thanks for your replying. I'm fine with the workaround, but I still hope for a more flexible solution in the future. I dug into the source code a little bit, and LocalDate, LocalTime, and LocalDateTime seem to be supported in the next version 3.4.0. Is that right? If that the case, can I suggest additional feature to support UUID type for primary key? For example, I want to map binary(16) to UUID.

Yes, in ver 3.4.0 the default types for date, time and timestamp will be the standard Java 8 Date/Time classes. A customizable type mapping in also under study. Regarding the UUID, indeed it's a need for many situations and I'm currently trying to find the best solution to manage it. As the type-mapping is "neutral type" to "target language type" I think that the best way is to add a new neutral type : "uuid" in order to be able to map it easily with the adequate target-language type (eg "java.util.UUID" for Java) and target-database type (eg "uuid" for PostgreSQL). Do you agree with that?

For UUID, the other option is to always store it as a "string" ( eg "a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11" ) in both application (Java code) and database. In this case the Telosys model could be something like this : --- fieldName : string { @UUID } ; ---

Yes, I agree. There are different support types for UUID from different database, and you would use other types like String for it to suit your use case. So, in this case, a dynamic mapping would be appropriate. I don't know whether it is a hassle to implement that feature or not, but it is definitely great if Telosys has such an option. Oh, and the DSL model. It's great that tag allows having flexible extension to model, but I don't use DSL model that often. Do we have similar feature like tag for model generated from database? A side note here is the models generated from database do not recognize unique constraint or unique index in the database, it it right?

Currently "tags" are not available for "db-model". The DSL-model has now a lot of features (yes, more than db-model). In the long term the idea is to use the same grammar for the 2 models. In future versions the db-model will be a DSL-model with a database-description (a table description for each entity), thus it will be possible to edit each entity (and table description) with a text editor and they will have the same capabilities Regarding metadata retrieved from the database, indeed unique constraint and indexes are not retrieved.

That will be a great improvement. I can’t wait for a new major version, or perhaps a few minor versions :)) For now, everything works for me except a few minor things we discussed. I don’t mind the workaround and minor edits. I’ll leave feedback here if I encounter any further problems. Thank you for your time.