CocoHeads this Thursday!

[Jeff Rock]

OK, folks. We're going to do something a little different this for
this month's CocoaHeads; we're actually going to have one! Jamie
Pinkham will be presenting on Core Data to get us back in the flow of
having an actual meeting.

We will be meeting in the Corrugated Box building in Manchester at 7PM
on Thursday July 14th. For whoever's interested afterward we'll be
walking next door to Legend to have a few beers.

I know it's short notice but hope to see everyone there!

Here's a map:

http://maps.google.com/maps?q=201+w+7th+st+23224&hl=en&sll=37.0625,-95.677068&sspn=76.63862,76.816406&z=17

[Tony Zatelli]

Excellent!! I'll be there.

> --
> You received this message because you are subscribed to the Google Groups "CocoaHeads Richmond" group.
> To post to this group, send email to cocoahead...@googlegroups.com.
> To unsubscribe from this group, send email to cocoaheads-rich...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cocoaheads-richmond?hl=en.
>

[Jim Kubicek]

Oh snap! I’m out of town until next week. Any interest in a make-up trip to Legend some time in the following week or two?

Jim Kubicek
jkub...@gmail.com

[Jeff Rock]

Sure!

[Tobias O'Leary]

Thanks for the update.
I'll be there too.
It'll be nice to meet some developers in Richmond.

I don't know if I've introduced myself, but I'm Tobias O'Leary.
Moved up to Richmond 3 weeks ago, wife is working at VCU.
I work from home for a consulting company called Lokion Interactive based in Memphis, TN.

Cocoa is a hobby mostly. Most of my projects are in Java, .NET, and PHP.

-Tobias

[Tony Zatelli]

Tobias,

I have yet to meet the group as well. I look forward to meeting you and everyone else on Thursday night.

-Tony

[Jonathan Lumpkin]

I'll be there.

[Zachery Bir]

On Jul 12, 2011, at 1:59 PM, Jeff Rock wrote:

I'm in.

Zac

[Mike Schrag]

wife sign-off ... i'm in

[Ryan Castillo]

First time attender also. Been following the group for a while.
Finally in a position to start doing iOS development. See you guys in
a couple of days!

- Ryan

--
Ryan Castillo
http://myfakeif.blogspot.com/

[Tobias O'Leary]

I think I got here too early. Where are we meeting in the corrugated box? The downstairs noodle bar formally savory cafe is packed.

-Tobias

[Tobias O'Leary]

Jeff came and got me we're up the stairs in the back left

-Tobias

On Jul 12, 2011, at 3:57 PM, Ryan Castillo <rmca...@gmail.com> wrote:

[Tobias O'Leary]

Moving to the conference room now.

-Tobias

On Jul 12, 2011, at 3:57 PM, Ryan Castillo <rmca...@gmail.com> wrote:

[Eddie Peloke]

Hope the meeting went well.  Sorry I missed it.  Really want to make it to the next one.

Eddie

[Mike Schrag]

Here's a follow up on how CD migrations work, after reading up some:

- CD uses the version hash to figure out which model version your persistent store corresponds to -- each version has a different hash, auto-computed by default, but manually configurable if you need to explicitly override it

- CD supports versioned xcdatamodels, where each model verison is stored separately which its version info, and one designated as "current"

- To manually migrate between two models, you can define a "Mapping Model" that specifies the data mapping between an old model and a new model (1-2, 2-3, etc).

- Mapping Models can specify custom entity migration policy classes to migrate something more than a simple schema change.

- For a defined set of common schema changes, CD can infer a mapping model for you based on the versioned models, by comparing each model to the previous model. This is the recommended approach for most straightforward migrations.

- When you choose to create a new model version, it will make "Model", "Model 2", "Model 3", files. The name doesn't matter, so my guess is that CD stores the versionHash of the previous model inside the new model, so it can always build the lineage in order (at least .... that's how i'd do it).

- My guess is that you CAN create an optimized mapping model to go from 1 to 4 or 2 to 10, but that most people will do 1-2, 2-3, 3-4, and CD will execute the migrations in order of the versionHash sequence or based on your corresponding mapping models (which explicitly declare the old and new).

ms

[Mike Schrag]

> - My guess is that you CAN create an optimized mapping model to go from 1 to 4 or 2 to 10, but that most people will do 1-2, 2-3, 3-4, and CD will execute the migrations in order of the versionHash sequence or based on your corresponding mapping models (which explicitly declare the old and new).

Correction here from the horse's mouth: The default impl is to look for a direct mapping model from version x to y, but you can drop down and use the migration api to execute in sequence. LWM is recommended in almost all cases except for "excessively complex" migrations. For excessively complex (which they defined as splitting or joining entities), you would need to drop back and write the custom migration, and mix-and-match between LWM and custom mapping model (so you could LWM 1-5, nasty 5-6, LWM 6-10, etc).

ms

[Tobias O'Leary]

Maddox you left your glasses at legends.

-Tobias