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?
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?
Comments
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?