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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #11724: -[EOModel writeToFile:] broken

Submitted by:  Dirk Lattermann <dlatt>
Submitted on:  Mon 24 Jan 2005 09:06:46 PM UTC  
 
Category: gdl2Severity: 3 - Normal
Item Group: Change RequestStatus: Invalid
Privacy: PublicAssigned to: David Ayers <ayers>
Open/Closed: Closed

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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 4 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Fri 11 Feb 2005 10:23:11 AM UTCayersOpen/ClosedOpen=>Closed
Wed 09 Feb 2005 12:04:50 PM UTCayersItem GroupBug=>Change Request
  StatusNone=>Invalid
  Assigned toNone=>ayers

Back to the top


Powered by Savane 3.1-cleanup1