On 2014 Sep 11, at 15:38, Rick Mann wrote:
> The problem is, I now have to specify the destination URL explicitly, and I'm
> not able to give it the source URL. So, I create a new sqlite data file, and
> that's fine. But the old sqlite DB actually has three files (DB.sqlite,
> DB.sqlite-shm,
Up until now I've performed a complex Core Data migration using Mapping Models
and custom migration policy subclasses, but initiated automatically upon
creating the persistent store coordinator, and it works fine. But
unfortunately, it's taking too long, so I have to initiate it man
According to the documentation, passing nil for the last argument to
-sourceInstancesForEntityMappingNamed:destinationInstances: or
-destinationInstancesForEntityMappingNamed:sourceInstances: is supposed to
return all the instances. When I call these in
-createDestinationInstancesForSourceInsta
Hi all,
>>
>> Doing a Core Data migration (not the lightweight kind) I hit an error at the
>> end:
>>
>> "foo is a required value."
>>
>> the 'foo' relationship it complains about is transient and so not present in
>> the s
On 2014 May 20, at 07:21, Sean McBride wrote:
> As a test I made the relationship optional, then it no longer complains.
Consider leaving it that way, Sean. The only effect I’ve ever had from setting
Core Data properties to be non-optional is the creation of mysterious errors
and exceptions
On 20 May 2014, at 15:21, Sean McBride wrote:
> Hi all,
>
> Doing a Core Data migration (not the lightweight kind) I hit an error at the
> end:
>
> "foo is a required value."
>
> the 'foo' relationship it complains about is transient and so not pr
Hi all,
Doing a Core Data migration (not the lightweight kind) I hit an error at the
end:
"foo is a required value."
the 'foo' relationship it complains about is transient and so not present in
the store. Normally, I recreate the relationship in awakeFromFetch, but it
On 2014 Feb 23, at 01:07, Yi Lin wrote:
> After reading Apple’s docs on migration policy subclasses, I find it very
> convoluted
I don’t find mapping models or NSMigrationPolicy to be any more complex than is
necessary. There are some holes in the documentation which you’ll need to
search ar
I am changing the model of my Core Data app in a big way for the next
update, and custom migration is definitely needed. After reading Apple's
docs on migration policy subclasses, I find it very convoluted and wondered
if there is an easier way. I am thinking, why not just bring up the data in
the
On Tue, 5 Mar 2013 18:56:32 -0800, Jerry Krinock said:
>> I take it you are using your technique successfully in practice?
>
>Maybe not. I'd pasted in some of my code but modified it for your
>case. Although I have done a lot of stuff in that method, I'm not sure
>if I have ever used that specif
On 2013 Mar 05, at 14:25, Sean McBride wrote:
> I take it you are using your technique successfully in practice?
Maybe not. I'd pasted in some of my code but modified it for your case.
Although I have done a lot of stuff in that method, I'm not sure if I have ever
used that specific techniq
On Mon, 4 Mar 2013 22:17:44 -0800, Jerry Krinock said:
>This is easy to do with a mapping model, migration policy and migration
>manager. In your NSMigrationManager subclass implementation, implement
>an override something like this…
>
>- (BOOL)createDestinationInstancesForSourceInstance:
>(NSMan
Correcting the message I just sent, wherever I mentioned subclassing
NSMigrationManager, I meant subclassing NSMigrationPolicy.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list
On 2013 Mar 04, at 14:38, Sean McBride wrote:
> What's a good way to delete some managed objects from a store when migrating
> the store from version x to version y? Basically, for entity 'Foo', I'd like
> for instances that match predicate 'bar' to not exist in the new store.
This is easy t
Hi all,
What's a good way to delete some managed objects from a store when migrating
the store from version x to version y?
Basically, for entity 'Foo', I'd like for instances that match predicate 'bar'
to not exist in the new store.
In the headers, I see a "NSRemoveEntityMappingType", which s
s so
>> loudly that the still, small voice of the Greater Self, whose whisperings
>> come from within the Soul, are rarely heard - unless we learn to listen."
>>
>>
>>
>> On Feb 25, 2013, at 8:36 AM, cocoa-dev-requ...@lists.apple.com wrote:
>>
>
On Feb 25, 2013, at 6:28 PM, Michael Swan wrote:
> Tom,
> I've never built a data model programmatically but I'm guessing it works like
> building a nib in code where it happens on each launch. This means that when
> you move to version 2 of your data model you will have to build model 1 and
cocoa-dev-requ...@lists.apple.com wrote:
> Message: 9
> Date: Mon, 25 Feb 2013 07:27:03 -0600
> From: tshanno
> To: Cocoa Dev List
> Subject: Programmatic Core Data Migration
> Message-ID:
> Content-Type: text/plain; charset=us-ascii
>
> I'm at an early stage of developing my ap
I'm at an early stage of developing my application and up to this point
whenever I've made a changes to the core data model, I've simply trashed the
old one and reimported default data. However I'm now at a point where I'd like
to begin using the thing and, as a result, I want to keep the old d
On 2012 Apr 04, at 16:40, Sean McBride wrote:
> How do I update my existing .xcmappingmodels to point to version 4 instead of
> 3?
>
> When viewing the xcmappingmodel in Xcode 4, should I use the 'destination'
> popup and change it from 3 to 4? After doing so, and diffing its
> xcmapping.xml
Hi all,
My Mac app currently has 3 versions of my xcdatamodel. I have explicit
.xcmappingmodels for 1->3 and 2->3 (they pre-date lightweight migration).
I now need to create version 4. Let's assume it's a trivial change from 3.
Thus, I hope to do 3->4 with lightweight migration. In fact, cu
I'm not using autosave. In fact this is done in my document controller before
the NSPersistentDocument is even created. Does the Core Data stack have some
awareness of an autosave mode? Perhaps, as you suggest, Apple has dropped this
feature and this is just a documentation bug. Hope someone fro
On 2011 Jul 31, at 21:18, Dave Fernandes wrote:
> I just found a strange thing on Lion: the backup~ file doesn't get produced
> with in-place lightweight migration. The same binary *does* create the
> backup~ file on Snow Leopard, though. Has anyone else noticed this?
Have not noticed it becau
to core data migration one day … :(
>
> I've read the documentation a couple of times and it says that the default
> migration process finishes by renaming the old store to the same thing with a
> tilde prefix. Does that mean you, the programmer, are responsible for
> deleti
On 2011-07-21, at 12:16 PM, Roland King wrote:
> Great - thanks for this - gets me started, I've found the documentation quite
> dense and soon I have to pitch in and just give it a go (I have a model I
> need to update in my test app and I really don't want to toss the data).
>
> I need to h
el
> inferredMappingModelForSourceModel:destinationModel:error:]. You may end up
> with cases where you have to use your own mapping model for some migrations.
>
> Dave
>
> On 2011-07-21, at 8:31 AM, Roland King wrote:
>
>> I suppose I had to get to core data migr
+[NSMappingModel
inferredMappingModelForSourceModel:destinationModel:error:]. You may end up
with cases where you have to use your own mapping model for some migrations.
Dave
On 2011-07-21, at 8:31 AM, Roland King wrote:
> I suppose I had to get to core data migration one day … :(
>
I suppose I had to get to core data migration one day … :(
I've read the documentation a couple of times and it says that the default
migration process finishes by renaming the old store to the same thing with a
tilde prefix. Does that mean you, the programmer, are responsible for deletin
On 2011 Jan 16, at 17:31, Michael Link wrote:
> This migration is using the default mapping model created in Xcode. The Event
> entity was changed to have an abstract parent entity, before it stood alone.
Migrating abstract entities can be problematic. For example,
http://www.cocoabuilder.com
I keep getting this error when trying to migrate a sql store:
-[Document
configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error:]
Error NSCocoaErrorDomain 134110 {
NSUnderlyingException = "I/O error for database at
/Users/mlink/Desktop/Untitled.db.new. SQLit
On 2010 Sep 13, at 15:38, Jerry Krinock wrote:
> …I found that Xcode accepted my input if I set "Source Fetch" to Default and
> entered one of these as "Filter Predicate":
>
>($source.beak != nil) // Bird
>($source.beak == nil) // Fish
Upon studying my situation a little furt
ntity had a relationship to Beak, 'beak', used for Birds only.
Aha!
I can't find any examples, but I've guessed that the "Source Fetch" is what I
need. I created two Entity Mappings, AnimalToBird and AnimalToFish. After
trying various incantations from the Core
What a pain this has been for me. I have finally narrowed down the culprit for
an error during migration of core data.
When I run migration without including MediaPlayer.framework my app runs fine...
2010-09-13 10:41:33.942 Test[3446:207] beginEntityMapping
2010-09-13 10:41:35.803 Test[3446:20
Hi Jerry,
On 24 May 2010, at 2:29 PM, Jerry Krinock wrote:
> I did as Quincey suggested and it fixed the bug in my multi-stage automatic
> migration.
>
> Indeed, FSExchangeObjects() is documented as:
>
> "... allows programs to implement a “safe save” operation by creating and
> writing a com
I did as Quincey suggested and it fixed the bug in my multi-stage automatic
migration.
Indeed, FSExchangeObjects() is documented as:
"... allows programs to implement a “safe save” operation by creating and
writing a complete new file and swapping the contents. An alias, FSSpec, or
FSRef that
On May 23, 2010, at 18:11, Jerry Krinock wrote:
> To perform Core Data migration automaticlly, my overridden
> configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error:,
> archives the original document by invoking -[NSFileManager
> moveItemAtPath:::],
To perform Core Data migration automaticlly, my overridden
configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error:,
archives the original document by invoking -[NSFileManager moveItemAtPath:::],
appending a tilde (~) to its name, then migrates the document to a
Oh sorry, forgot to 'reply all'
my bad.
Thanks,
Chaitanya Pandit
Expersis Software Inc.
On Dec 22, 2009, at 7:12 PM, Jerry Krinock wrote:
>
> On 2009 Dec 21, at 23:16, Chaitanya Pandit wrote:
>
>> Hi jerry,
>> I think what i'll have to do is if the user closes the doc without saving,
>> just
On Dec 20, 2009, at 11:40 pm, Chaitanya Pandit wrote:
> One weird thing that is happening is that just after the
> "configurePersistentStoreCoordinatorForURL..." call, the contents of my
> document on the disk are changed, even if i didn't save the document
>
It's not clear in what sense this
cally load the old
tilde document if it couldn't load the current document due to model changed.
I recently had alot of trouble with Core Data migration, and saw alot of crap,
but never saw a migration occur without the tilde doc appearing. If you figure
out how you broke it, let us
..." method. as described in this
awesome link: http://www.timisted.net/blog/archive/core-data-migration/
One weird thing that is happening is that just after the
"configurePersistentStoreCoordinatorForURL..." call, the contents of my
document on the disk are changed, even if i d
On Sep 2, 2009, at 4:51 AM, Ian Kennedy wrote:
Hi all,
How would I go about doing a one-time migration of application data
from an xml persistent store to a sqlite persistent store? i.e. the
model stays the same, the data is migrated, and the app uses the
sqlite store from there on out.
Hi all,
How would I go about doing a one-time migration of application data
from an xml persistent store to a sqlite persistent store? i.e. the
model stays the same, the data is migrated, and the app uses the
sqlite store from there on out.
I've been unsuccessfully trying to do it inside
On Thu, May 7, 2009 at 1:19 PM, Adam Swift wrote:
> Unless you are specifying NSIgnorePersistentStoreVersioningOption as an
> option to addPersistentStoreWithType:...
I'm not.
> ... if there are any changes to your
> data model that would result in changes to the data that is persisted
> ...
On May 7, 2009, at 7:02 AM, I. Savant wrote:
On Wed, May 6, 2009 at 6:36 PM, Melissa J. Turner
wrote:
Context is important. Also future-proofing.
If your app was originally written against v1 CoreData (Tiger),
you need to
update the app to be wise enough to check the store's metadata a
On Wed, May 6, 2009 at 6:36 PM, Melissa J. Turner wrote:
> Context is important. Also future-proofing.
>
> If your app was originally written against v1 CoreData (Tiger), you need to
> update the app to be wise enough to check the store's metadata and run away,
> run away from any store containi
Dear Apple Developer Engineering Team (Dev Support, Dev Tools, Core
Data, and anyone else who works for Matt Firlik):
I miss Enterprise Objects Framework for the Desktop. Badly.
I know the Objective-C codebase is sitting somewhere in an old CVS or
Subversion repository deep in the bowels of
Context is important. Also future-proofing.
If your app was originally written against v1 CoreData (Tiger), you
need to update the app to be wise enough to check the store's metadata
and run away, run away from any store containing unexpected values (ie
version hash information). v1 CoreDa
List:
I'm having some trouble solving what I believe is a basic task with
Core Data. That is, the proper handling of a v1 user opening a v2
file. I want to disallow it altogether. The app in question targets
10.5 and above and (hopefully) uses automatic versioning / migration.
I added a new vers
On Apr 7, 2009, at 12:28 PM, Timothy Larkin wrote:
I think that Jon is asking whether he should give a version number
to his data model, and not whether he should create a second version
of his data model. If this is in fact his question, then I think the
answer is yes, because this will m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think that Jon is asking whether he should give a version number to
his data model, and not whether he should create a second version of
his data model. If this is in fact his question, then I think the
answer is yes, because this will make it
On Apr 7, 2009, at 10:53 AM, Jon Munson II wrote:
I wasn't certain if, in order to utilize versioning later, that I
would need to mark the current model in some way. The Apple dox
didn't state one way or another, and I didn't wish to make an
assumption and find out later that I missed som
I wasn't certain if, in order to utilize versioning later, that I
would need to mark the current model in some way. The Apple dox
didn't state one way or another, and I didn't wish to make an
assumption and find out later that I missed some important step which
would result in hours of hea
On Apr 7, 2009, at 9:34 AM, Jon C. Munson II wrote:
One thing I cannot readily determine from the documents is whether one
should begin with a "versioned" model. By "begin" I mean the model is
versioned from the start as opposed to later in the application's life
cycle.
So, my question is: is
Namaste!
I would like to be able to take advantage of the migration tool that comes
with Core Data.
One thing I cannot readily determine from the documents is whether one
should begin with a "versioned" model. By "begin" I mean the model is
versioned from the start as opposed to later in the app
Having worked through this problem myself, I can offer a few
suggestions. First, some kind list member pointed out to me that the
automated migration function does not support abstract classes. So you
have to outwit Apple.
I created a custom migration policy for the abstract class by
subc
Back on March 29 2008, Mr. Wilson reported a problem with migration
that I seem to be having now. To wit, a core data model that includes
an abstract entity and entity inheritance fails to be migrated on OS X
10.5.
I'm getting different errors than he reported. I created a mapping
model f
On Thu, Sep 11, 2008 at 8:02 PM, Adam Swift <[EMAIL PROTECTED]> wrote:
> No, you'll need to do a manual migration so you can register yourself as an
> observer of the NSMigrationManager's migrationProgress
Thanks Adam, I figured that was the case. I didn't want to spend much
time on this feature
On Sep 11, 2008, at 8:08 AM, Doug Penny wrote:
I have a core data store that I am migrating using the
default/automatic migration process. It seems to work very smoothly,
but takes a minute or two to complete. I would like to provide some
type of feedback to the user to let them know what is
I have a core data store that I am migrating using the
default/automatic migration process. It seems to work very smoothly,
but takes a minute or two to complete. I would like to provide some
type of feedback to the user to let them know what is going on and
possibly a progress indicator. Is thi
David,
To sum up:
Relationships to entities from which another entity inherits are not
automatically set up properly.
Unfortunately. This is a known issue.
Anyone have any experience with this, or know how to handle this
situation? I suppose I could write a whole bunch of custom code to
han
I have a reasonably complex core data data model which makes use of
entity inheritance. In an attempt to make use of the new Leopard data
migration tools, I created a new version, made a few minor desired
changes (added a few entities and created the relationships to them-
no changes to existing en
62 matches
Mail list logo
