bugGNUstep - Bugs: bug #11724, -[EOModel writeToFile:] broken

Group
 
 

bug #11724: -[EOModel writeToFile:] broken

Submitter:  Dirk Lattermann <dlatt>
Submitted:  Mon 24 Jan 2005 09:06:46 PM UTC
   
 
Category:  gdl2 Severity:  3 - Normal
Item Group:  Change Request Status:  Invalid
Privacy:  Public Assigned to:  ayers
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 11 Feb 2005 10:23:11 AM UTC, comment #2: 

After some private feedback we agreed on not trying to reset the name and path if the write operation fails.  Yet the main issue that loadAllModelObjects actually didn't load all objects which lead to lazy loading during the save operation when the files had alread been moved to the backup directory, has been resolved in CVS.

David Ayers <ayers>
Group Member
Wed 09 Feb 2005 12:04:50 PM UTC, comment #1: 

Hello Dirk,
I've spent some time looking into this and with the exception of the noop of loadAllModelObjects which I now have implemented in CVS, this is the expected behavior.

I admit it is counter intuitive but calling -writeToFile: has the side effect of changing the name and path of the model in memory independent of whether the write is successful or not.

I’m inclined to interpret a the state of the model as undefined by the API therefore allowing us to change this behavior to cache the old name and path and reset it to the old value of writing fails.  OTOH this adds extra complexity that I’m not really fond of either.

For now I’ll put this report on "invalid" but I’ll wait for you thoughts before adding documentation and closing the bug report.

As to validation, there is actually very little validation that I could encounter in WO4.5.  In fact I know of production applications that use certain constructs that EOModeler warns about when saving but are crucial to the correct execution of the app.  So unless we have a very good reason to force correct values in -writeToFile: I think we should leave it as it is.  Is there a specific issue that you are worried about?

David Ayers <ayers>
Group Member
Mon 24 Jan 2005 09:06:46 PM UTC, original submission:  

I. This method sets the receiver's path early.

1. This may be problematic in case of a failure: when the method doesn't complete because of some error, the EOModel's path should not be modified (I guess).

2. Strangely, in this method, the model tries to read some information from the file given by path. As it has modified its path by then, this fails.

Even if I call -initWithContentsOfFile: and then loadAllModelObjects, the model wants to read something from file during -writeToFile:.

3. In EOModel.m, moving the call [self _setPath: path] from the top of -writeToFile: to the very end seems to help, but I don't know if there are side effects.

II. after creating a model with an .eomodeld-file by -initWithContentsOfFile:, writing it to a file effectively copies the old file, even when there are nonsensical key = value pairs in the plist dictionaries. Is this ok? Also, there are no default values for omitted keys written to the output file. Is this ok, too?

Dirk Lattermann <dlatt>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-02-11 ayers Open/ClosedOpen Closed
2005-02-09 ayers Item GroupBug Change Request
    StatusNone Invalid
    Assigned toNone ayers

Back to the top

Powered by Savane 3.13-02a9.
Corresponding source code