This is non-deterministic (or more accurately, its entirely deterministic but is an unreliable 'feature' upon which to base your persistent objects as its an internal behavior that might be open to change in the future).
The better approach in this case is probably to map to properties instead of fields and handle any special behaviors of interdependent backing fields within the property setters and/or getters. If you have two fields in your object whose values are temporally or sequentially interdependent and this cannot be stated in terms of their property getters/setters then you likely need to rethink your class design. Can you elaborate on a (real-world) use-case for this situation --? -Steve B. On Aug 3, 8:28 am, Mark Kharitonov <[email protected]> wrote: > Dear folks. > > If the order in mapping does not do this, then how can I make one > field to be dependent on the other? Meaning, I wish a certain field to > be already set when another field is being set. > > Thanks. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
