I support this change. We just need to be sure old databases get upgraded > without too many issues. > > I think we need a new predefined attribute type called phone number. The > we will know where to look for phone numbers. >
Yes. > When it comes to encryption, do we then encrypt all attribute values? > Will be hard to know which of the dynamic attributes that are > privacy-related, e.g. name, address etc. > > Or do we include another property on the attribute to define whether it > should be encrypted or not? > Hm. Great point. The problem is that encryption must happen per-column, not per-row. So if we are to encrypt some attributes and not others, we need to split into two tables. I can now also see that Jasypt <http://www.jasypt.org/hibernate.html> (the lib we plan to use for encryption) is not as transparent as we hoped: "But encryption sets a limitation on your Hibernate usage: security standards establish that two different encryption operations on the same data should not return the same value (due to the use of a random salt). Because of this, none of the fields that are set to be encrypted when persisted can be a part of a WHERE clause in your search queries for the entity they belong to." So it seems we must think closer here. While at it, should we combine dynamic attributes and identifiers as one > object, or we continue to keep them separate? The identifier is strictly > speaking just a special attribute type or? What are the pros and cons here? > From the users' point of view this would certainly be a simplification. > Could be a good idea. I guess the main difference is that identifiers are unique, but we cannot enforce relational uniqueness constraints anyway (since we have many identifier types in the same table) so we don't lose much by combining them. Time to 2.14 is a factor here too. Lars
-- Mailing list: https://launchpad.net/~dhis2-devs-core Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs-core More help : https://help.launchpad.net/ListHelp
