DTO's or id's as Instance variables?

[Alfonso Mateos Alarcón]

Is it better to store a PersonDTO inside my instance variables, or just to store personDto.personId?

Is it a good practice to store DTO's so that I can seize the BPM storage capabilities, without having to store them to my domain tables? 

Or is it a good practice to keep my database up to date after every single activity?

Thanks in advance!

[Daniel Meyer]

Hi Alfonso,

You can have a look at this excellent post (and the comments) by cyberwebrob or https://groups.google.com/d/msg/camunda-bpm-users/KDLIEUEyb6E/BjivXMSOUJ0J

Usually it is not best practice to store any Serialized Java DTOs as process variables since the process engine will use Java Bytecode serialization for storing the Java Object instances in the database. This has at least 2 major downsides:

1. You cannot easily inspect the values of these variables using SQL and using a monitoring Tool like cockpit
2. If you try to deserialize the objects and the Java classes have changed (application patch/update), this can lead to all sorts of nasty problems caused by the objects being serialized based on some version 1 of a class and being attemted to be deserialuzed using some version 2 of a class. 

If you want to strore complex data as process variables, it is better to store it as XML, JSON or some other text-based format. 

Cheers,

Daniel Meyer

[A Holbreich]

Hi Daniel,

ist there any hard size limit (maybe DB specific?) for String variables with XML content?

Or how could it be avoided i the current version?

We have to avoid such problems at a begining of a project. 

Best Regards,

Alexander 

[Christian Lipphardt]

Hi Alexander,

We use the default size of 4000 for VARCHAR / CHAR / TEXT columns used to store text data in our database creation scripts.

This size is only a starting point. When you need more space, just increase it to your needs / your database supports.

Cheers

Christian