On 19.02.2011 16:36, Mark wrote:
If you already use a database in the project and if the project is depending on the operation of the database, than I would say that there is no reason that is sufficient to justify the use of a property file beside the database. Especially when you have many users which are all configuring their stuff.I have an application that requires a great deal of configuration data after the app is running and needs to be configurable by the end user from within the application This includes things like Facebook admin id, Twitter account info, Mailchimp api key, etc.So far I've been just creating objects, storying them in the database and then accessing them using Hibernate. However this is getting a bit cumbersome and I'd prefer to use some type of properties file that I can configure by hand or have the end user update from within the application. So it needs to be something where: 1. If the property is changed it gets saved back to the file. 2. Changes can be made at run time without reloading the application.
Reinventing a wheel in such case would be to NOT use the database (you will have the problems of multi-user concurent access and file-locking, versioning, ACID transactions).
I would also add that you shouldn't split the user profile personal data from the user profile configuration data - they are both user personal data and according to privacy-related laws should be protected. If you split it, than you will have two separate locations to deal with and protect (database and file).
Most web applications I have seen that have a lot of user configuration data, store it in a single table that will mimic the property file, that has a composite key like this:
(#userid, #property-key, value)Is this what you're currently doing? Because from what I read, it sounded like you are creating separate entity classes for separate properties.
smime.p7s
Description: S/MIME Cryptographic Signature
