Tuesday, February 22, 2011

Make sure you do not lock unnecessary attributes in an entity in a WebObjects EO model

One more mistake many people doing EOModelling with WebObjects make - unnecessarily locking attributes.

In the EOModeller tool, all new attributes come with the locking option set to 'on'. I have no idea why. This really should have a default of 'off'. The locking attribute is used when an update is being made to the database. During the actual update, the attributes that are set as 'locked' are used in the 'where' clause of the update query being sent to the database.

Typically, you would only need the primary key when you are updating a single row. Now, if you have set another attribute to be locked and you are trying to update that same attribute, you will get a 'GeneralAdaptorException'. That's because, you set the attribute to be locked and you are trying to update it!

The problem is the tool sets everything to be locked by default. What I have started doing is to set everything to unlocked except the primary and foreign keys which you never ever update in WebObjects. That has worked well for me.

Does anyone have any more insight into this?

2 comments:

Shravan Kumar. M said...

Actually I think here WO has chosen a better design (framework being made responsible for data integrity) over developer convenience.

Given this, framework has to make clever choice of which attribute of your entity is responsible for data integrity (which in most cases would be primary and foreign keys), however, this being a very sensitive area, WO has no choice other than forcing lock on all attributes and let developers think twice about it before unlocking it :)

Would you agree?

Kartik said...

It's an extremely defensive approach actually. By locking all attributes by default, it ensures that no data is overwritten. I guess in most cases we wouldn't need that kind of an approach. However, WO chooses reliability over speed by default, and I guess we can pick what is right for us depending on the context - I would prefer to limit it to the primary keys though.