Menu
▾
▴
nhibernate-issues
|
From: NHibernate J. <mik...@us...> - 2006-11-16 21:22:34
|
Resetting of properties after initial set violates constraints we want to p=
rotect
---------------------------------------------------------------------------=
------
Key: NH-814
URL: http://jira.nhibernate.org/browse/NH-814
Project: NHibernate
Type: Improvement
Versions: 1.0.2 =20
Reporter: Jim Showalter
We have properties on objects that are supposed to be set only once, when f=
irst reading an object back from the database. Once in memory, they are not=
supposed to be set again, and attempting to do so is supposed to throw an =
exception. Unfortunately, nhibernate's behavior appears to be less predicta=
ble than we had thought. It assigns properties more than once. For example,=
when merging a disconnected object, it loads one from the database (thus s=
etting the properties), and then sets them again from the other object, thu=
s violating the set-once rule. There are other cases similar to this. We mo=
dified our rule to allow setting to null (or some other value indicating no=
t-yet-set) as many times as desired, then setting to some actual value, and=
allowing setting to that same value as many times as desired. Setting to a=
different value once set throws an exception. This seems to pacify nhibern=
ate, but we're not certain that it will work in all cases, and the behavior=
of nhibernate as far as resetting properties is concerned is undefined. Ou=
r request is for nhibernate to be enhanced to have a notion of set-once, wh=
ich would be stated in the HBM file. This would make a property immutable, =
with the sole setting of that property to be done on reading in from the da=
tabase. On save, a set-once property would be assumed to have already been =
set--nhibernate would not set it itself when saving, only when reading.
This same request has been filed for hibernate as HHH-2245.
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nhibernate.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: NHibernate J. <mik...@us...> - 2006-11-17 05:08:34
|
[ http://jira.nhibernate.org/browse/NH-814?page=3Dall ] Sergey Koshcheyev updated NH-814: --------------------------------- Fix Version: LATER Component: Core > Resetting of properties after initial set violates constraints we want to= protect > -------------------------------------------------------------------------= -------- > > Key: NH-814 > URL: http://jira.nhibernate.org/browse/NH-814 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.2 > Reporter: Jim Showalter > Fix For: LATER > > We have properties on objects that are supposed to be set only once, when= first reading an object back from the database. Once in memory, they are n= ot supposed to be set again, and attempting to do so is supposed to throw a= n exception. Unfortunately, nhibernate's behavior appears to be less predic= table than we had thought. It assigns properties more than once. For exampl= e, when merging a disconnected object, it loads one from the database (thus= setting the properties), and then sets them again from the other object, t= hus violating the set-once rule. There are other cases similar to this. We = modified our rule to allow setting to null (or some other value indicating = not-yet-set) as many times as desired, then setting to some actual value, a= nd allowing setting to that same value as many times as desired. Setting to= a different value once set throws an exception. This seems to pacify nhibe= rnate, but we're not certain that it will work in all cases, and the behavi= or of nhibernate as far as resetting properties is concerned is undefined. = Our request is for nhibernate to be enhanced to have a notion of set-once, = which would be stated in the HBM file. This would make a property immutable= , with the sole setting of that property to be done on reading in from the = database. On save, a set-once property would be assumed to have already bee= n set--nhibernate would not set it itself when saving, only when reading. > This same request has been filed for hibernate as HHH-2245. --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 06:57:29
|
[ http://jira.nhibernate.org/browse/NH-814?page=3Dcomments#action_1442= 2 ] =20 Ayende Rahien commented on NH-814: ---------------------------------- It there a reason you cannot use a nosetter access strategy? That would by pass your properties. > Resetting of properties after initial set violates constraints we want to= protect > -------------------------------------------------------------------------= -------- > > Key: NH-814 > URL: http://jira.nhibernate.org/browse/NH-814 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.2 > Reporter: Jim Showalter > Fix For: LATER > > We have properties on objects that are supposed to be set only once, when= first reading an object back from the database. Once in memory, they are n= ot supposed to be set again, and attempting to do so is supposed to throw a= n exception. Unfortunately, nhibernate's behavior appears to be less predic= table than we had thought. It assigns properties more than once. For exampl= e, when merging a disconnected object, it loads one from the database (thus= setting the properties), and then sets them again from the other object, t= hus violating the set-once rule. There are other cases similar to this. We = modified our rule to allow setting to null (or some other value indicating = not-yet-set) as many times as desired, then setting to some actual value, a= nd allowing setting to that same value as many times as desired. Setting to= a different value once set throws an exception. This seems to pacify nhibe= rnate, but we're not certain that it will work in all cases, and the behavi= or of nhibernate as far as resetting properties is concerned is undefined. = Our request is for nhibernate to be enhanced to have a notion of set-once, = which would be stated in the HBM file. This would make a property immutable= , with the sole setting of that property to be done on reading in from the = database. On save, a set-once property would be assumed to have already bee= n set--nhibernate would not set it itself when saving, only when reading. > This same request has been filed for hibernate as HHH-2245. --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 19:27:30
|
[ http://jira.nhibernate.org/browse/NH-814?page=3Dcomments#action_1442= 6 ] =20 Jim Showalter commented on NH-814: ---------------------------------- If nhibernate can access fields directly, then so can anyone/anything else.= If they can do that, then the constraints aren't protected. So field acces= s is deliberately shut off using declarative security. So nosetter doesn't = work. Think of nhibernate in the context of a high-security application. For exam= ple, a banking application. We don't want malicious code to be able to call= a method to change a person's account balance. But we have to allow nhiber= nate to set that balance when it reads an object back from the database. So= we have to allow the balance to be set once by nhibernate. But we don't wa= nt anything that isn't authorized to do so to set that balance again. > Resetting of properties after initial set violates constraints we want to= protect > -------------------------------------------------------------------------= -------- > > Key: NH-814 > URL: http://jira.nhibernate.org/browse/NH-814 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.2 > Reporter: Jim Showalter > Fix For: LATER > > We have properties on objects that are supposed to be set only once, when= first reading an object back from the database. Once in memory, they are n= ot supposed to be set again, and attempting to do so is supposed to throw a= n exception. Unfortunately, nhibernate's behavior appears to be less predic= table than we had thought. It assigns properties more than once. For exampl= e, when merging a disconnected object, it loads one from the database (thus= setting the properties), and then sets them again from the other object, t= hus violating the set-once rule. There are other cases similar to this. We = modified our rule to allow setting to null (or some other value indicating = not-yet-set) as many times as desired, then setting to some actual value, a= nd allowing setting to that same value as many times as desired. Setting to= a different value once set throws an exception. This seems to pacify nhibe= rnate, but we're not certain that it will work in all cases, and the behavi= or of nhibernate as far as resetting properties is concerned is undefined. = Our request is for nhibernate to be enhanced to have a notion of set-once, = which would be stated in the HBM file. This would make a property immutable= , with the sole setting of that property to be done on reading in from the = database. On save, a set-once property would be assumed to have already bee= n set--nhibernate would not set it itself when saving, only when reading. > This same request has been filed for hibernate as HHH-2245. --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 21:43:31
|
[ http://jira.nhibernate.org/browse/NH-814?page=3Dcomments#action_1442= 7 ] =20 Ayende Rahien commented on NH-814: ---------------------------------- Accessing the fields directly usually means either reflection or dynamic co= de generaion, not something that your everyday code is going to be able to = do. I don't agree with this approach of handling security, since if you have ma= licious code in your appdomain that is able to make calls, you are in a bad= state already. But, this discussion is not for the JIRA. Given the constraints that you have set, I would create an access strategy = where the strategy would inform the object that it is being modified by NHi= bernate, and disallow any modifications not done this way. A simple approach may be setting a flag to say that NHibernate is now doing= modification to the object, and having the object check that flag. Securing this approach is possible by putting the flag in a base class and = making it internal, so only the access strategy could access it. > Resetting of properties after initial set violates constraints we want to= protect > -------------------------------------------------------------------------= -------- > > Key: NH-814 > URL: http://jira.nhibernate.org/browse/NH-814 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.2 > Reporter: Jim Showalter > Fix For: LATER > > We have properties on objects that are supposed to be set only once, when= first reading an object back from the database. Once in memory, they are n= ot supposed to be set again, and attempting to do so is supposed to throw a= n exception. Unfortunately, nhibernate's behavior appears to be less predic= table than we had thought. It assigns properties more than once. For exampl= e, when merging a disconnected object, it loads one from the database (thus= setting the properties), and then sets them again from the other object, t= hus violating the set-once rule. There are other cases similar to this. We = modified our rule to allow setting to null (or some other value indicating = not-yet-set) as many times as desired, then setting to some actual value, a= nd allowing setting to that same value as many times as desired. Setting to= a different value once set throws an exception. This seems to pacify nhibe= rnate, but we're not certain that it will work in all cases, and the behavi= or of nhibernate as far as resetting properties is concerned is undefined. = Our request is for nhibernate to be enhanced to have a notion of set-once, = which would be stated in the HBM file. This would make a property immutable= , with the sole setting of that property to be done on reading in from the = database. On save, a set-once property would be assumed to have already bee= n set--nhibernate would not set it itself when saving, only when reading. > This same request has been filed for hibernate as HHH-2245. --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2007-07-17 20:26:59
|
[ http://jira.nhibernate.org/browse/NH-814?page=3Dcom.atlassian.jira.pl=
ugin.system.issuetabpanels:comment-tabpanel#action_15722 ]=20
Nels P. Olsen commented on NH-814:
----------------------------------
Having your property setters ignore requests to reassign the same value sho=
uld be sufficient. Beyond that it is merely a potential optimization to NH=
ibernate to keep it from repeatedly setting the a property to the same valu=
e. All of our entity property setters ignore requetsts to reassign the sam=
e value, both so that some properties can enforce the "set once" rule, and =
also so that PropertyChanged events (all our entities implement INotifyProp=
ertyChanged) don't get fired and time isn't otherwise wasted validating the=
value.
> Resetting of properties after initial set violates constraints we want to=
protect
> -------------------------------------------------------------------------=
--------
>
> Key: NH-814
> URL: http://jira.nhibernate.org/browse/NH-814
> Project: NHibernate
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.0.2
> Reporter: Jim Showalter
> Priority: Major
> Fix For: LATER
>
>
> We have properties on objects that are supposed to be set only once, when=
first reading an object back from the database. Once in memory, they are n=
ot supposed to be set again, and attempting to do so is supposed to throw a=
n exception. Unfortunately, nhibernate's behavior appears to be less predic=
table than we had thought. It assigns properties more than once. For exampl=
e, when merging a disconnected object, it loads one from the database (thus=
setting the properties), and then sets them again from the other object, t=
hus violating the set-once rule. There are other cases similar to this. We =
modified our rule to allow setting to null (or some other value indicating =
not-yet-set) as many times as desired, then setting to some actual value, a=
nd allowing setting to that same value as many times as desired. Setting to=
a different value once set throws an exception. This seems to pacify nhibe=
rnate, but we're not certain that it will work in all cases, and the behavi=
or of nhibernate as far as resetting properties is concerned is undefined. =
Our request is for nhibernate to be enhanced to have a notion of set-once, =
which would be stated in the HBM file. This would make a property immutable=
, with the sole setting of that property to be done on reading in from the =
database. On save, a set-once property would be assumed to have already bee=
n set--nhibernate would not set it itself when saving, only when reading.
> This same request has been filed for hibernate as HHH-2245.
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://jira.nhibernate.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X