Re: findReference, or create it ?

Hello Franck,

I had a very brief look through the change log.

What happens if a record is created, with initial value on column C that is not later set.  C is not dirty, so does not get inserted.  Then it is read again.  Do we reinitialize the values?  How do we know that they were not deliberately set to null (say)?

I also noted
  this.setRawArrayValue(fld, fld.getInitialValue())
We normally cook the values a bit, which sets dirty.  I see why you used raw, but it may not be quite right.  Have a think.  Needs documenting.

I'm wondering if they should be normal sets, make the column dirty, cause it to be updated.  Only set when a new record R is created, which now makes R dirty anyway.  Would seem simpler to me, and avoids both problems.

Initializations are messy.  Are they really useful to you?

Need to document that no DDL is generated.


Your observation on references seems sound.  Really, the only way that there could be a reference to a row that does not exist is if the database is corrupted somehow.   So Find would seem to make more sense.  So my initial reaction is to change it to a find, no create, exception if not found.  Be sure to put this slight incompatibility in the change log.

Regards,

Anthony


At 07:01 PM 26/01/2009, you wrote:

>Hi,
>
>I have implemented the setInitialValue that was discussed on the list a
>few week ago.
>
>An example can be found in examples.Department.
>Usage is fieldMeta.setInitialValue(ival);
>
>Then your record will have the value of this field set to ival each a
>_new_ record is created. So this will happen on create,
>createWithNullKeys and findOrCreate in the case when the record is not
>found.
>Giving an initailValue to a primaryKey has no much sense, as the primary
>keys are always explicitely given on creation, or set to null, but doing
>so won't hurt.
>InitialValue does not change the way dirtiness is handled.
>
>So, implementing this, I came accross a behaviour I was not aware of :
>findReference will really fnd _or create_ a reference ! I don't know if
>this was done on purpose, but I think anyone should concious about it.
>
>And my question : is this really the desired behaviour ?
>
>Franck
>
> 


Spreadsheet Detective,
Southern Cross Software Queensland Pty Limited
54 Gerler Street
Bardon, Queensland 4065, Australia.

Email: [email protected]
www.SpreadsheetDetective.com
Ph: +61 427 830248 (Australian Eastern Standard Time)

"If the model seems correct only because the numbers look right, 
then why build the model in the first place?"

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/