So far, manual migration has the same result. migrateStoreFromURL returns
NO. I even tried deleting a new entity and one attribute from the mapping
model, both of which are not involved in the migration. All the others are
straightforward.
To rule out some other problems, I also set up a
On 2011 Feb 10, at 18:37, Gordon Apple wrote:
The error handles gives 10 console messages, The operation couldn’t be
completed, which is the exact number of records in the test database. So
something is definitely going awry in the mapping.
Log these errors' -userInfo. In particular, look
On Feb 8, 2011, at 9:08 PM, Gordon Apple wrote:
I am trying to migrate an existing app CoreData database to a new version.
Theoretically, this should be what's called a simple migration. I have not
been able to get it to work. Just to see what it's trying to do, I went
ahead and let it
On Tue, 8 Feb 2011 17:07:00 -0600, Fritz Anderson fri...@manoverboard.org
said:
On 8 Feb 2011, at 2:51 PM, Quincey Morris wrote:
P.S. It's OT, but initializing 'error' to nil before passing it to an
error-returning method is both a waste of time and semantically incorrect --
it's an *output
On Feb 9, 2011, at 09:09, Matt Neuburg wrote:
From Bill Bumgarner:
If the method fails -- if file is nil -- the 'error' will be filled in
with an [autoreleased] NSError instance describing the error.
However, 'enc' will be undefined.
If the method succeeds, file and enc will be
Date: Tue, 8 Feb 2011 17:07:00 -0600
From: Fritz Anderson fri...@manoverboard.org
Subject: Initializing NSError **, again Re: CoreData Migration
Problems
I'm filing a bug against the documentation because it's flat wrong; or if
it's right, it's a workaround for a bug
PM, Matt Neuburg m...@tidbits.com wrote:
Date: Tue, 8 Feb 2011 17:07:00 -0600
From: Fritz Anderson fri...@manoverboard.org
Subject: Initializing NSError **, again Re: CoreData Migration
Problems
I'm filing a bug against the documentation because it's flat wrong; or if
it's right, it's
On Feb 9, 2011, at 11:19 AM, Bill Bumgarner wrote:
On Feb 9, 2011, at 10:51 AM, Matt Neuburg wrote:
error
An out value that returns any error encountered during initialization.
Returns nil if the regular expression pattern is invalid.
Really? :) m.
I read that as The method
On Feb 9, 2011, at 10:34 AM, Quincey Morris wrote:
The real world cost in all of this is that it's easy for a developer to
misunderstand the 'error:' parameter mechanism, in such a way as to code an
error handling scheme that depends on initialization to a nil value to work
properly.
On 9 Feb 2011, at 11:04 AM, Scott Anguish wrote:
If you pass blah, if there is no error, blah == nil
Perhaps by-reference would be a better terminology.
Returns, by-reference, an NSError object if the regex is invalid; otherwise
nil. Pass nil if you don't care.
My understanding is that
On Feb 9, 2011, at 2:02 PM, Wim Lewis wrote:
3. If the method succeeds, it will not modify *error.
This is incorrect, I think. If the method succeeds, then *error may or may not
have been modified.
(The documentation also regularly confuses nil, NULL, and NIL.)
nil and Nil and NULL are
On Feb 9, 2011, at 12:46, Greg Parker wrote:
Initializing the error to nil is helpful to protect against one nasty hole in
the pattern. Consider this code:
NSError *error;
id result = [receiver doSomethingWithError:error];
if (!result) NSLog(@error %@, error);
On failure,
I am trying to migrate an existing app CoreData database to a new version.
Theoretically, this should be what's called a simple migration. I have not
been able to get it to work. Just to see what it's trying to do, I went
ahead and let it generate a mapping model, which appears to be correct.
On Feb 8, 2011, at 12:08, Gordon Apple wrote:
persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel: self.managedObjectModel];
NSError *error = nil;
NSPersistentStore* store =
[persistentStoreCoordinator
Guess I'm just in the habit of initializing things. :-)
PersistentStoreCoordinator is non-nil. Store returns nil. Console just
gives the infamous message: Storage:persistentStoreCoordinator The
operation couldn¹t be completed. (Cocoa error 1560.)
On 2/8/11 2:51 PM, Quincey Morris
On 8 Feb 2011, at 2:51 PM, Quincey Morris wrote:
P.S. It's OT, but initializing 'error' to nil before passing it to an
error-returning method is both a waste of time and semantically incorrect --
it's an *output only* parameter to the method. OTOH, setting it to nil isn't
inherently
On 8 Feb 2011, at 5:07 PM, Fritz Anderson wrote:
The documentation for AVAudioPlayer's initWithContentsOfURL:error: and
initWithData:error: methods, however, call for the address of a
nil-initialized NSError object, whatever that is. I think they mean a
nil-initialized pointer to an
On Feb 8, 2011, at 15:07, Fritz Anderson wrote:
The documentation for AVAudioPlayer's initWithContentsOfURL:error: and
initWithData:error: methods, however, call for the address of a
nil-initialized NSError object, whatever that is. I think they mean a
nil-initialized pointer to an NSError
On 2011 Feb 08, at 13:21, Gordon Apple wrote:
PersistentStoreCoordinator is non-nil. Store returns nil.
Well, -addPersistentStoreWithType:configuration:URL:options:error: is only
being passed trivial parameters, except for the URL. Log that URL and make
sure that its parent directory
19 matches
Mail list logo
