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:
http://homepage.mac.com/kelleherk/iblog/C711669388/E20070719095201/index.html
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.
--
Seeya...Q
Quinton Dolan - [EMAIL PROTECTED]
Gold Coast, QLD, Australia (GMT+10)
Ph: +61 419 729 806
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
