On 23/05/2008, at 12:50 PM, Rams wrote:
Hi Everyone,
Please pardon me if I am asking extremely stupid questions, but I'm starting to do some work with my database and I have a few questions about EnterpriseObjects and database things in general...
The first question is about creating unique data... I have a user object and I need unique usernames for obvious reasons. Now, I know it is unlikely, but let's say that two visitors attempt to create a user at the same time and they happen to pick the same username.
EOQualifier qualifier = User.SCREEN_NAME.eq(username);
if(User.fetchUser(ec, qualifier) == null) {
User.createUser(ec, email, password, username);
ec.saveChanges();
}
If these fired at the same time, is it possible that two users with the same username could be created? If so, does anyone have any pointers to prevent duplicate data?
You need to create a uniqueness constraint on this field in your database. The database is the only place that can guarantee this uniqueness requirement is honoured.
The second question regards security/sql injection. Is there any sort of user input I should be on the lookout for in my validateUsername method? Like username "admin'--" or some such? I assume that as long as I stick to EOQualifiers and don't touch the SQL myself that all the input will be properly escaped...
As long as you don't send anything through EOF as raw SQL you should be safe from SQL injection attacks.
Finally, third question... I'm using MySQL. I will ensure InnoDB is used by default as mentioned here:
Is there anything else I need to do in order to produce ACID transactions with WO? It doesn't hurt to be buzzword compliant you know ;-)
I am not sure about 5.1, but last time I tested MySQL 5.0 with it's default configuration (but using InnoDB), it was in my opinion NOT ACID compliant. InnoDB might be ACID compliant, but MySQL itself isn't.
One of the edicts of ACID is data consistency throughout the course of a transaction. If the transactions leaves the database in an illegal start then the transaction should be aborted and rolled back. MySQL doesn't actually do this, instead of aborting the transaction it will quietly alter the invalid data that it was provided, eg. shorten a string, alter a date, truncate an integer, etc so that it no longer violates the integrity constraint and then commits it anyway.
This results in a situation where the data that you thought you successfully inserted into the database is different from what you will get back later, which in my opinion should NEVER happen, EVER. EOF will shield you from most of this if your model and validation is decent, but it's a risk to your data that you will always need to keep at the back of your mind.
Using an enterprise level database such as Frontbase or PostgreSQL is also worth considering.