Re: NSMutableData and Pinned Memory buffers..
On Dec 13, 2012, at 4:28 PM, Kevin Perry kpe...@apple.com wrote: On Dec 13, 2012, at 4:24 PM, Greg Parker gpar...@apple.com wrote: On Dec 13, 2012, at 4:13 PM, Robert Monaghan b...@gluetools.com wrote: I went ahead and created a really crude subclass of NSMutableData. It seems to work for my situation. Attached is the code, for posterity. (I am sure I won't be the only one working around this.) Any suggestions to make this a bit more Proper are welcome. If that's all you need then you should wrap the buffer in an immutable NSData. NSData won't mind if you poke directly at the contents of the buffer. Except that he's probably expecting to be able to invoke -mutableBytes and modify the buffer's contents without changing the length. Immutable NSData objects don't respond to -mutableBytes. There's no reason he needs to invoke -mutableBytes. For his purposes, -bytes would do just as well, since the length won't be changing. +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: What does core data do during a Save As?
On Oct 1, 2010, at 10:02 PM, Jerry Krinock wrote: On 2010 Oct 01, at 10:44, Quincey Morris wrote: Core Data implements Save As as a migration process using a mapping model that it constructs on the fly Eeek. I never knew that. I'm late to the game, but this is incorrect. The Save As functionality does not use the migration feature. Save As simply(?) loads all the objects, messes with the objectIDs, and saves to the new location. This means that all the standard rules for loading objects (ie don't touch relationships in awakeFromFetch) apply, and any business logic your classes implement on save will be triggered (unlike migration, which modifies the model to use NSManagedObject instead of custom classes). +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Finding Core Data objects in Instruments
On Aug 30, 2010, at 7:35 PM, Rick Mann wrote: We're having a hard time tracking down our smaller leaks in our iPad app. When running on the simulator, one thing we noticed is that none of our Core Data objects shows up in Leaks or Allocations (all of them have custom NSManagedObject subclasses). Does Core Data never actually instantiate our objects, instead somehow usurping each individual action implementation and instantiating its own kind of objects? Why do we not see NSManagedObject, nor any of our subclasses, in Leaks or Allocations? Some from column A, some from column B. CoreData will create custom subclasses of your classes and instantiate those instead of your classes (this shows up if you run heap from the command line). More relevant to your question, CoreData uses a different allocation path than most of the rest of Cocoa with the result that many objects allocated by CoreData (particularly those which are allocated in bulk, like object ids, managed objects, etc) appear in Leaks/Allocations as anonymous malloc blocks. You should be able to play around with allocating extra instances during startup to figure out what block size maps to what managed object class(es). +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Managed Object with Transformable Attribute (C Struct)
On Dec 15, 2009, at 20:47, Richard Somers wrote: On Dec 15, 2009, at 9:18 PM, Graham Cox wrote: You're archiving 'value'. You want instead to return the mutableData that the first archiver wrote to, which is otherwise unused. Thanks. Saving keyed archive of struct foo now works for xml store (I think, when I open up the xml document I was expecting to see the keys for foo but instead just see data as before). Prior to this change document saved ok in xml and sqlite but save as binary resulted in error: *** -[NSKeyedArchiver encodeValueOfObjCType:at:]: this archiver cannot encode structs. With this change saving to xml is ok but saving as sqlite or binary results in error: The document could not be saved as document.foo is a required value. My whole application works fine with core data, bindings, saving to different store types, etc. Just this one attribute is causing problems. Any ideas? I think you're running into a known problem with the binary store not respecting the value transformer name and instead always using the default archiver (NSKeyedArchiver). The only real workaround is to have a wrapper property (ie a property returning an NSData) that does the transform and persist that instead. +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data: insertNewObjectForEntityForName doesn't return my custom subclass during migration
On Dec 3, 2009, at 09:08, Sean McBride wrote: Hi all, The docs for NSEntityDescription say initWithEntity:insertIntoManagedObjectContext: returns an instance of the appropriate class for the entity. This seems to be mostly true. Yet when I do: [NSEntityDescription insertNewObjectForEntityForName:@FooBar inManagedObjectContext:moc]; it's giving me an NSManagedObject not an RRFooBar. I've confirmed that by sending the class method and also sending message that only my subclass responds to. I've confirmed that my xcdatamodel has specified the right subclass (RRFooBar). This happens only during migration (the same code gives RRFooBar if migration is not involved). Specifically during this partial backtrace: ... -[NSEntityMigrationPolicy createRelat ionshipsForDestinationInstance:entityMapping:manager:error:] -[NSMigrationManager(InternalMethods) _doSecondPassForMapping:error:] -[NSMigrationManager migrateStoreFrom URL:type:options:withMappingModel:toD estinationURL:destinationType:destinationOptions:error:] ... Is this expected? This is expected. During migration, Core Data uses NSManagedObject instead of custom subclasses to contain object data. This is to avoid triggering application logic and/or validation rules in the classes during what should be a pure data transformation step. Any logic you need during migration should be encoded into the mapping model. +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Help debugging Dangling reference to an invalid object. Core Data error
On Oct 22, 2009, at 16:26, Sean McBride wrote: Hi all, Core Data is giving me a validation error when I try to save a document after making a simple change. I have an entity 'Scene' with a to-many relationship to an entity 'Target'. The inverse relationship is also to-many. Both relationships are optional and the delete rule for both sides is nullify. To repro, I delete all Scenes then try to save. It gives: Dangling reference to an invalid object. = null; NSAffectedObjectsErrorKey = ( BSScene: 0x2004ff940 (entity: Scene; id: 0x2004f32a0 x-coredata:// FCE3E0E3-F187-4C44-BFC3-60D7AF3E579F/Scene/p343 ; ... This error gives only 4 hits with Google. :( The problem is that some Targets still have relationships to some Scenes! How can that happen? It seems like the delete rule is not doing its job. I've confirmed that each Scene receives prepareForDeletion. None of the Scenes are finalized, they are all strongly referenced by the moc's _deletedObjects ivar. Any advice on how to debug this? (I can repro this with 2 customer-provided documents, but I've not been able to create a document with this problem myself. Happens on 10.5.8 and 10.6.1; my app is garbage collected.) Does the object with the ID x-coredata://FCE3E0E3-F187-4C44-BFC3-60D7AF3E579F/Scene/p343 exist in the affected store? What happens when you call existingObjectWithID:error:? Do you know what version of the OS the bad documents were created on? A lot changed in the relationship handling area in 10.6 (for the better, really and truly ;-), so knowing whether your customers created them on 10.5.x or 10.6.x would help narrow down the possibilities. +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data fetch with to-many relationship
On Sep 8, 2009, at 18:03, Alex Reynolds wrote: Relationship fault for (NSRelationshipDescription: 0x3d1b2b0), name Book, isOptional 1, isTransient 0, entity Owner, renamingIdentifier Book, validation predicates ( ), warnings ( ), versionHashModifier (null), destination entity Book, inverseRelationship Owner, minCount 0, maxCount 0 on Owner 123456 | username That's not an error, it's an unfired to-many relationship fault. If you call a method on it (say [testFetchResults valueForKey:@name]) it will fire and look more like what you're expecting. BTW, it's generally a bad idea to use uppercase key names. The ivar 'Book' should probably be 'books', and 'Owner' should be 'owner' (the class names are fine the way they are). +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Finder-style sorting and the SQL Core Data store, best practice?
As of SnowLeopard, Core Data supports the following selectors for sorting in the SQLite store: compare: (since Tiger(I think)) caseInsensitiveCompare: (since Leopard) localizedCompare: (new in SL) localizedCaseInsensitiveCompare: (new in SL) localizedStandardCompare: (new in SL) The last comparison type is new to the OS in SL, and will get you the system standard sort as done by Finder. As to subclassing NSArrayController, I'll leave that to people with more UI-fu. +Melissa On Sep 1, 2009, at 13:10, Sean McBride wrote: Hi all, The Troubleshooting Core Data document discusses the FAQ SQLite store does not work with sorting. It suggests: you may need to subclass NSArrayController so you can have it not pass the sort descriptors to the database and instead do the sorting after your data has been fetched. [1] I imagine this must have been done many times over by many people. Try as I may, I cannot find any example code, or even a more detailed discussion of what to override. I fear there may be edge cases overriding such an important class, so want to be careful. My ultimate goal is for all table and outline views in my app to sort correctly (ie like the Finder[2]). What is the correct way to achieve this? [1] http://developer.apple.com/mac/library/documentation/Cocoa/ Conceptual/CoreData/Articles/cdTroubleshooting.html [2] http://developer.apple.com/mac/library/documentation/Cocoa/ Conceptual/Strings/Articles/SearchingStrings.html Thanks, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CoreData / SQL hang on save
On Aug 25, 2009, at 02:19, Greg Hoover wrote: I've run into a hang in CoreData save. I'm the single coordinator, multiple object contexts threading model and a SQL store (though it seems to happen with XML as well). The hang occurs inside the NSSQLCore and seems to just loop endlessly. The SQL output supports this. Requests performed at launch succeed as expected, but the app quickly reaches a point where Optimistic locking failure exceptions are thrown with an endless sequence of ROLLBACKs followed by UPDATEs. All of the contexts are using the MergeByPropertyObjectTrump merge policy. Any insight would be much appreciated. There is a known issue on 10.5.* that results in Core Data entering an infinite loop during save if the database has been corrupted such that the optimistic locking column is set to NULL. A way to tell would be to run sqlite3 on the database and execute the following SQL statement: select Z_PK, Z_OPT from ZSTOCK where Z_PK IN (1, 4); I'm guessing you'll get back something that looks like: 1| 4| Which means that something has stuffed unexpected NULLs into your database. The issue has been fixed in 10.6, but the only real workaround on 10.5.* is to manually repair the database by setting the value of the Z_OPT column to be non-null (1 is always a good option). Cheers, +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CoreData / SQL hang on save
Could you try running with -com.apple.CoreData.SQLDebug 3? I'm curious as to what's trying to bind that's causing this: binding not implemented for this SQLType 7 Cheers, +Melissa On Aug 25, 2009, at 14:12, Greg Hoover wrote: Hi Melissa, Thanks for you response. The problem actually just started showing up in 10.6 (wasn't a problem in 10.4 or 10.5). :-/ The hang stopped for a few launches and reverted to its previous output: binding not implemented for SQLType 7. But then it happened again... The SQL file does not have null values for any Z_OPT fields. CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET ZEPS = ?, ZASK = ?, Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET ZOPEN = ?, Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET ZEPS = ?, ZASK = ?, Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: ROLLBACK binding not implemented for this SQLType 7 safe save CoreData: sql: BEGIN EXCLUSIVE CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET ZEPS = ?, ZASK = ?, Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET ZOPEN = ?, Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: UPDATE ZSTOCK SET ZEPS = ?, ZASK = ?, Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: ROLLBACK binding not implemented for this SQLType 7 CoreData: annotation: total fetch execution time: 0.s for 0 rows. CoreData: annotation: total fetch execution time: 0.s for 0 rows. safe save Thanks, Greg On Aug 25, 2009, at 1:16 PM, Melissa J. Turner wrote: On Aug 25, 2009, at 02:19, Greg Hoover wrote: I've run into a hang in CoreData save. I'm the single coordinator, multiple object contexts threading model and a SQL store (though it seems to happen with XML as well). The hang occurs inside the NSSQLCore and seems to just loop endlessly. The SQL output supports this. Requests performed at launch succeed as expected, but the app quickly reaches a point where Optimistic locking failure exceptions are thrown with an endless sequence of ROLLBACKs followed by UPDATEs. All of the contexts are using the MergeByPropertyObjectTrump merge policy. Any insight would be much appreciated. There is a known issue on 10.5.* that results in Core Data entering an infinite loop during save if the database has been corrupted such that the optimistic locking column is set to NULL. A way to tell would be to run sqlite3 on the database and execute the following SQL statement: select Z_PK, Z_OPT from ZSTOCK where Z_PK IN (1, 4); I'm guessing you'll get back something that looks like: 1| 4| Which means that something has stuffed unexpected NULLs into your database. The issue has been fixed in 10.6, but the only real workaround on 10.5.* is to manually repair the database by setting the value of the Z_OPT column to be non-null (1 is always a good option). Cheers, +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data dog-slow when using first time after boot
On Aug 20, 2009, at 02:35, Ruotger Skupin wrote:
Complex locale aware Unicode text queries can be slow. If you
find yourself spending time with such a query, you should consider
some of the techniques shown in the DerivedProperty example
available on ADC.
Isn't all text Unicode?
No. Not all apps are Unicode based, and many of the ones that aren't
will put things on the pasteboard quite happily. The web (and thus
anything copied out of a web browser) is definitely not all Unicode,
especially the older pages. And even within Unicode there are
multiple encoding formats (8. 16, and 32 bit). In addition to the
varying encoding sizes, Unicode also has multiple ways to represent
conceptual characters. Characters that have diacritics for example,
can be represented as either one Unichar ('é') or two ('´' + 'e').
I don't understand. This shouldn't be a special case. But I will
have a look at the sample.
In my case I'd guess that at least half of the objects contain
unicode strings (international names and addresses). What I want to
say: write anything in German or French and you end up with Unicode.
Due to the multiplicity of representations, text comparisons in
Unicode can be slow, since instead of just doing a byte by byte
comparison, you end needing to calculate character sizes, check for
compositions/decompositions, check for analogues between different
symbol systems used to represent a single language (ie kana and
kanjii), recognize and drop punctuation, etc. For apps that do
repeated comparisons against a set of strings, it can be worth it to
preprocess all strings into one canonical format to minimize the
amount of work that needs to be done during a comparison (make all
strings UTF8/16/32, make all characters lowercase, strip all
diacritics or ensure characters that have them are always in either
their composed or decomposed forms, etc) and then use a less expensive
collation for the comparison.
As a side node, if you want to use regular expressions on Unicode
strings, you generally need to do the normalization anyway, since
regex languages operate at the Unichar level rather than at the
conceptual character level.
+Melissa
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Clarification of NSPredicate constraints for Core Data SQL store
On Jun 30, 2009, at 09:44, Barry Wark wrote:
In the Constraints and Limitations section of the Predicate
Programming Guide
(http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/Articles/pBasics.html#//apple_ref/doc/uid/TP40001792-249799
),
the second bullet states than only one operator (ALL, IN, ANY) and
only one instance of that operator per query. I can't find any
reference to such a limitation in the SQLite documentation, so I
assume that this is an NSPredicate or Core Data limitation. From the
doc, it seems that a predicate with a format @self.first_name IN
{'Joe', 'Bob', 'Bertha'} OR self.last_name IN {'Smith', 'Jones'} is
illegal. It seems that this is quite restrictive. In true lazy web
style, can any one confirm whether this restriction is really per
query or whether it is per clause in a compound predicate?
That's a bad paragraph. (The documentation I mean. Yes, a bug has been
filed.)
The CoreData SQLite store:
1) Does not support ALL
2) Supports as many IN/ANY clauses as you want
3) Does not support more than one to-many component in a single
keypath, but will support multiple keypaths each of which contains a
single to-many (your performance will probably stink because you're
doing lots of joins)
All of these are true for Leopard and SnowLeopard, and may or may not
continue to be true into the future, as the SQL generation is a work
in progress. This is not a full listing of the restrictions, but you
can play around with various predicates and see what happens.
Cheers,
+Melissa
(ps http://bugreporter.apple.com is a great place to let us know if
there's something you really need/want)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Core Data Migration and the Inexperienced Younger Self
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 CoreData always assumes that it can open a store it was told to open until later evidence proves otherwise; later versions of CoreData realized that was perhaps an unwise decision, and added the current versioning and migration infrastructure. Due to binary compatibility issues, applications compiled on Tiger will continue to exhibit the old behavior. There's a general discussion of migration under 10.4 at http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdZ104Versioning.html#//apple_ref/doc/uid/TP40002989 Later versions of CoreData always check the store metadata for version hash information, which is affected by things that could change the schema (adding and removing entities and/or persistent properties, adding or removing validation rules, etc), but not by things that don't change the schema (adding or removing transient properties, adding or removing default values). For more details, see the Core Data Model Versioning and Data Migration Programming Guide, and for a concrete discussion of what affects version hashes, the section on versioning (http://developer.apple.com/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmVersioning.html#//apple_ref/doc/uid/TP40004714-SW1 ). An application controlled technique would be to add an application specific piece of metadata (a version # perhaps) to your stores, and have your various application versions categorically refuse to open a store whose app version is = the version it knows how to read. This can allow for a better user experience than the default NSPersistentStoreIncompatibleVersionHashError returned by addPersistentStore, which is a bit vague about which newer version of the application you need to buy to open a given file. Cheers, +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
(apologies for the delay; I've been on vacation for the last few days and just got back) On Apr 28, 2009, at 14:32, Kyle Sluder wrote: So step 1 is to stop clinging to normalization rules. (My database professor would kill me for that sentence, but it's true.) There really is no redundancy here, because the data stored on disk is never really separated from the model objects which use that data. In an n-tier app, you would be correct to avoid storing the derived property. Even in an n-tier application there are situations where it makes more sense to denormalize data than cling to theoretical purity. Once common case is to avoid joins, because they're *expensive*. Sometimes, the dba level pain of maintaining duplicate/derived data is much less than the user level pain of doing a join to display information in a frequently accessed view. There's no general rule for when this becomes true, because it's data set and use dependent, and it's not something you should do casually or without understanding what you're doing, why, and what tradeoffs are involved, but it is part of building a schema that's does what you need it to do efficiently. You can see an example of denormalized data in the Leopard version of iCal. The badges on the corner of events in the varying day/week/month views displays meta-information about the relationship that contains the note/contact/etc data. Having the badge provides useful information (there are other people invited, click here for meeting material), but it's expensive to do the join just to decide whether or not to display that badge for any given event, so iCal stores a separate bit of information saying this event has notes/contacts/ etc. According to pure relational design, this is a Very Bad Thing, because it duplicates information that exists in the join tables and introduces the possibility of error into the database. According to real-world performance, not doing the join sped displaying those views up by an order of magnitude (more in the case of large calendars). Taking normalization to it's fullest extent, you end up with things like databases where a Person is a set of joins to a Names table (don't get me started on natural vs assigned integer keys ;-), but no one outside academia does that because it's overkill and inefficient for anything except theoretical work. As for the logic required to maintain this relationship, that's why we have KVC/KVO! Implement +keyPathsForValuesAffectingValueForKey: as appropriate. Implement your KVC setters/getters for the independent attributes such that they invoke -setPrimitiveValue:forKey: for the required dependent properties. This is what I was getting at, yes. Create a separate modeled property 'letterGrade' and have the mutator for 'percentageGrade' automatically update it whenever percentageGrade is changed. Add observers as necessary. +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On Apr 22, 2009, at 02:12, Mike Abdullah wrote: On 22 Apr 2009, at 08:48, Ben Trumbull wrote: Of course, why Apple couldn't have then added automatic support for in-memory matching as the second step I don't know Probably because nobody ever cared enough to file an enhancement request, and it didn't occur to us that writing 1 line of code to call filteredArrayWithPredicate was so troublesome. Calling -filteredArrayWithPredicate is no hassle, but for a large predicate, it has the bad performance of comparing a bunch of the persistent properties all over again, despite already knowing they'll match the predicate. Since I assume Core Data must do some kind of internal splitting up of the predicate in order to perform its fetch, I'd have thought it is in a good position to know what the remaining transient portion of the predicate is. You assume incorrectly. CoreData simply translates the predicate to SQL and passes it down to SQLite as a WHERE clause. Hence the lack of support for transient properties: SQLite has no idea what to do when you ask it to qualify by a column that doesn't exist in its schema. +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Implementing a many-to-many (reflexive) relationship using bindings and an NSTableView
On Mar 25, 2009, at 13:44, Jon C. Munson II wrote: [Jon C. Munson II] OK. Benjamin Stiglitz responded suggesting I take a look at the ToManyCheckbox example on mmalc's page, so I'll do that and see if that clarifies things. Also, I noticed in the iClass example that code is used to support the relationship and so on. Is that the recommended template implementation to support this type of relation? The purpose of the iClass example is to demonstrate how to construct and maintain relationships between objects in different persistent stores. Anything not required for that particular task is mostly an example of how to hack an example together in an afternoon under a deadline ;-) +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CoreData mystery: configuration used to open the store is incompatible...
There was a change between Tiger and Leopard in the way NSPersistentDocument loaded its model. If you have a document created on Tiger, the model is created using [NSManagedObjectModel mergedModelFromBundles: [NSBundle allBundles]], and on Leopard, with [NSManagedObjectModel mergedModelFromBundles: nil]. The problem with the first version is, as you've seen, as more and more frameworks start to include bundles, the model gets polluted with entities from things you don't care about. There's a check done at runtime to see which version you were compiled on, so you get the same runtime behavior for applications that were compiled and linked on Tiger that depended on the original behavior, but if you recompile on Leopard, you get the later, safer behavior. See: http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSPersistentDocument_Class/Reference/Reference.html#//apple_ref/occ/instm/NSPersistentDocument/managedObjectModel Cheers, +Melissa On Dec 15, 2008, at 14:52, Houdah - ML Pierre Bernard wrote: Hi! I am puzzled! I have run into this weirdest problem. It only happens if I target Tiger. I am working on an update to HoudahGeo and suddenly, my current build refuses to open documents. This includes both existing documents and documents created by the running application. The error is: Error Domain=NSCocoaErrorDomain Code=134020 UserInfo=0x2b7b10 The model configuration used to open the store is incompatible with the one that was used to create the store. NSUnderlyingException = Can't find table for entity MovieReference in database at URL file://localhost/Users/pierre/Desktop/HoudahGeo-Leopard.hgeo; There is no MovieReference entity in the model. There never was. Actually I have seen the same message with varying entity names. I believe they are taken from other applications. BTW, the model has not been updated in over a year. And most certainly not between saving and attempting to reopen using the same running application. The stack is: #0 0x96da7e17 in objc_exception_throw #1 0x9496344b in -[NSSQLCore _ensureDatabaseMatchesModel] #2 0x94962b35 in -[NSSQLCore load:] #3 0x94958732 in -[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:] #4 0x915f5fe9 in -[NSPersistentDocument configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error :] #5 0x915f6fab in -[NSPersistentDocument (NSPersistentDocumentDeprecated) configurePersistentStoreCoordinatorForURL:ofType:error:] #6 0x915f63b6 in -[NSPersistentDocument readFromURL:ofType:error:] #7 0x41c2 in -[Document readFromURL:ofType:error:] at Document.m: 177 #8 0x913f16c6 in -[NSDocument initWithContentsOfURL:ofType:error:] #9 0x913c1274 in -[NSDocumentController makeDocumentWithContentsOfURL:ofType:error:] #10 0x913c0898 in -[NSDocumentController openDocumentWithContentsOfURL:display:error:] This only happens when I target Tiger. When I target Leopard with the same code all works fine. It occurs on both 10.5.5 and 10.5.6 When I compile an older version of the project, it works just fine. Thus I broke something with my recent changes. Yet I have no idea what. I did not touch the model. Pierre ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/mjturner%40apple.com This email sent to mjtur...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CoreData -- addPersistentStoreWithType crashing
Hi Ben - What's the backtrace you get when you crash your application in the debugger? +Melissa On Dec 10, 2008, at 02:58, Ben Lachman wrote: Hi all: I've been making some changes to one of my apps which include a change to the data model. Now whenever I start up the app it crashes (EXEC_BAD_ACCESS) in addPersistentStoreWithType:configuration:URL:options:error:. I've factored out all the passed arguments and it's still crashing. I figure it must have to do with the change in the model, but I can't see why that would make it crash and not report an error or trow an exception, particularly if the URL points to a nonexistent file ) e.g. it will create a new store file). Any thoughts? Thanks, -Ben -- Ben Lachman Acacia Tree Software http://acaciatreesoftware.com email: [EMAIL PROTECTED] twitter: @benlachman mobile: 740.590.0009 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/mjturner%40apple.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Core Data request predicates and to-many relationships
On Dec 6, 2008, at 01:45, Luke Evans wrote: If there are any NSPredicate gurus out there, I'm scratching my head on this one: I have an entity that can optionally have a set of attributes (name- value pairs). This is set up in the model as a optional to-many relationship to an attribute entity. Now, I want to fetch the list of managed objects of this entity whose attributes exactly match a dictionary that is passed. The predicate for this needs to filter the objects that have all the required attributes; matching both the name, and value for each attribute. At this point I'm not seeing how you can code this in a predicate. If I AND some clauses like: ...ANY attr.name == %@ AND ANY attr.value == [EMAIL PROTECTED] for each attribute I'm testing for, then AFAICS I'm not testing that the _same_ attr has the name and value. I wondered about: ...ANY (attr.name == %@ AND attr.value == %@)... but this doesn't appear to be legal syntax. I'm still experimenting, but if anyone knows how to express a query that allows multiple clauses on the _same_ entity across a to-many relationship I'd appreciate a clue! Cheers Luke If you're targetting 10.5 or later, there's a subquery expression in the predicates that was added to support this kind of query. The syntax for what you're doing would be: SUBQUERY(toMany, $each, $each.name == %@ AND $each.value = %@)[EMAIL PROTECTED] 0 Note that this is on the list of expensive predicate operations, so it should be towards the end of a compound predicate. Cheers, +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Core Data request predicates and to-many relationships
On Dec 8, 2008, at 14:47, Luke Evans wrote: Thanks for the reply Melissa - much appreciated. I was beginning to toy with the idea of trying a function expression (which I have used before for other purposes) to isolate an individual attribute object and perform the several comparisons therein. Presumably SUBQUERY, being designed for the job, benefits from some performance advantages over the function approach(?). Regards Luke It depends on the query/dataset. There's no real way to tell until you run against a sample that's a good approximation the data your application will be working with. That sounds kind of fluffy, but as with most things, it's a tradeoff between the time spent doing the joins and the time it would take to do the fetch differently, which usually involves additional IO or in-memory computation. Subqueries are supported natively by CoreData/SQLite, so you do avoid a lot of the object instantiation you'd be dealing with if you were postprocessing the potential results (the set of objects without the correlated subquery) in memory. Another option is to invert the query: fetch all the destination objects which meet your criteria for the destination, set the request to prefetch the relationship you're actually interested in, then do a second fetch with (targetObjects IN [EMAIL PROTECTED]) and includesPropertyValues set to NO (the data is already in the row cache at this point). Cheers, +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Comparing the Class
On Oct 15, 2008, at 06:20, Ruotger Skupin wrote:
Hi,
when comparing the class of two objects I usually do [obj1
isKindOfClass:[obj2 class]]. But if I say have the Class as an input
value to a method:
- (void) bla:(Class) inClass
{
if (/* inClass is an NSString */)
{
// do stuff
}
else if (/* inClass is an NSNumber */)
{
// do other stuff
}
}
Is it save to compare like this:
inClass == [NSString class]
or do I have to e.g.:
[[NSNumber numberWithInt:0] isKindOfClass:inClass]
It's generally unwise to do this kind of thing if you're dealing with
class clusters or bridged classes (which category includes both
NSString and NSNumber). The class you actually get may not be what
you're expecting.
If you're doing it with your own classes, it's safer, but can be
fragile, since it's one more thing you're going to need to remember to
change if you change your inheritance hierarchy.
+Melissa
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Multiple persistent store coordinators gotchas?
On Oct 15, 2008, at 14:00, Dave Dribin wrote: Hello, I'm working on a Core Data application that does lots of processing of the data in background threads to generate reports. I'd like to investigate using multiple persistent store coordinators to reduce lock contention, i.e. pattern #2, as described in the multi-threaded chapter of the Core Data guide. I'm thinking it is a good fit in this case as the background threads are doing mainly read-only operations on the data. It does modify transient properties, but I think I can still get away with using a read-only store on the background threads. Is this correct? If your second thread is doing pure report generation, and whatever transients it sets won't affect anything outside the report generation, this is the solution you're looking for. The documentation is a little thin about using multiple PSCs. Is it just a matter of setting up separate Core Data stacks per thread? Yes. What are the downsides, especially compared to 1 PSC/multiple MOCs? Higher memory usage? Separate caches? Stale data? Anything else to watch out for? The downside tends to be more memory use, since you'll have two copies of all the data for each object that is loaded into both stacks in addition to the overhead of the stack itself. Stale data is unlikely to be a problem unless you're expecting to load it significantly before you actually need it, which would be the same if you were loading it into a separate context on the same coordinator. The big upside is that it decreases the amount of time your UI thread will be blocked on reads being done by the background thread. +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Multiple persistent store coordinators gotchas?
On Oct 15, 2008, at 17:41, Dave Dribin wrote: On Oct 15, 2008, at 5:52 PM, Melissa J. Turner wrote: The downside tends to be more memory use, since you'll have two copies of all the data for each object that is loaded into both stacks in addition to the overhead of the stack itself. Stale data is unlikely to be a problem unless you're expecting to load it significantly before you actually need it, which would be the same if you were loading it into a separate context on the same coordinator. Okay, great. This sounds ideal. One clarification. When you say two copies of all the data, doesn't this happen if you had 1 PSC and 2 MOCs, too? Each MOC has it's own copy of the data, since they don't share managed objects, right? Or is there some other data that is shared in the PSC? There's data cached down in the store as well, so if you have multiple copies of a store (multiple stacks), you have multiple copies of the data. If you have 1 PSC and 2 MOCs, we can leverage private information about the state of the context and the objects in it to decrease memory use (write only caching), but with 2 separate stacks, we lose that ability. Just don't try to load and dirty the world ;-) The big upside is that it decreases the amount of time your UI thread will be blocked on reads being done by the background thread. Precisely. I'm seeing some lock contention between the threads, and I want to reduce/eliminate that. BTW, this is a SQLite store. Do fetches do an exclusive SQL transaction, or is that only done for saves? Just curious if SQLite's locking will affect the threads at all, as we're seeing some fetches take a relatively long time (~3 seconds). Ideally, the SQLite database won't be locked for that period, either, which would also block the UI thread. We only open transactions when we update the database. Fetches take a read-only lock, so they'll block if there's a writer, and a would be writer will have to wait for any reads to finish before it touches any tables the reader is using, but overall you should see better performance. +Melissa ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Sub-classing NSAtomicStore
Todd - I'd suspect one of two things: 1) Your store's metadata method isn't returning the same identifier (ie @AtomicStore) you're passing to addPersistentStore, so the coordinator thinks the store isn't what the caller of addPersistentStore said it would be 2) Your store's metadata method is returning nil, and the coordinator thinks it isn't actually a store See the documentation at http://developer.apple.com/documentation/Cocoa/Conceptual/AtomicStore_Concepts/Articles/asLifecycle.html#//apple_ref/doc/uid/TP40004527-SW1 for what needs to happen when in order to avoid a confused coordinator. The key detail is: You must also initialize the metadata for the store. After initWithCoordinator:configurationName:url:options:, the coordinator invokes metadata on the new store; at this point the metadata must be correct. +Melissa On Jul 7, 2008, at 13:11, Todd Stanley wrote: Hi All, Has any one had any luck working with the AutomicStoreSubclass example. I need to manage and AtomicStore and thought that I would be able to use the AutomicStoreSubclass example as a road-map. When I addPersistentStoreWithType as follows - if ([coordinator addPersistentStoreWithType:@AtomicStore configuration:nil URL:url options:storeOptionsDict error:error]) I get the following error - Error Domain=NSCocoaErrorDomain Code=134010 UserInfo=0x162240 The store type is inconsistent with the data format. Anyone know of any gotchas when subclassing NSAtomicStore? Todd ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/mjturner%40apple.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Core Data entity required error
*Checks the oracle bones ... * Does the store configuration for your SQL store contain all the entities in your model? If not, you need to make sure that all the entities for objects you're trying to save into the store are in it. +Melissa On Jun 2, 2008, at 10:07, Hamish Allan wrote: On Mon, Jun 2, 2008 at 3:21 PM, Chataka [EMAIL PROTECTED] wrote: On the console, I just get entity required That's it. Just two words. Nothing else I can include... Ah, I see! Sorry, how frustrating. Try setting a breakpoint on NSLog() (or fprintf(), or syslog()) to see if you can get a stack trace on that message. Hamish ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/mjturner%40apple.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Immediate memory release
On Apr 30, 2008, at 19:59, Chris Suter wrote:
On 01/05/2008, at 12:27 PM, Jens Alfke wrote:
On 30 Apr '08, at 5:53 PM, Graham Cox wrote:
If some code throws an exception won't that mean that pool is
leaked? (and all of its contents up to that point too; applies to
both of our code examples).
Yup. You can work around that by using @finally:
for (i = 0; i count; i++)
{
NSAutoreleasePool* pool = [NSAutoreleasePool new];
@try{
NSImage* tempSource = [[[NSImage alloc]
initWithContentsOfFile:sPath[i]] autorelease];
// autorelease tempSource to ensure that we get cleaned up
if anything in 'some code' throws an exception.
// pool will automagically be released later if an
exception does happen and [pool release] get bypassed.
// some code
[EMAIL PROTECTED]
[pool drain];
}
}
This is wrong.
You mustn't drain or release autorelease pools in finally or catch
blocks because exception objects themselves are autoreleased.
It gets sorted out when a higher level autorelease pool is released.
This is documented somewhere in the docs.
Chris is correct.
If you really need to drain the pool, you need to
NSAutoreleasePool *pool = [NSAutoreleasePool new];
id exception;
@try {
// insert code here
} @catch (NSException *ex) {
exception = [ex retain];
@throw ex;
} @finally {
[pool drain];
if (exception) {
[exception autorelease];
}
}
(Disclaimer: coded in mail)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Adding CalendarStore.framework changes managed object model version?
Brad - At a guess, you're somehow pulling in CalendarStore.calmom into your model. This might happen if you're doing [NSManagedObjectModel mergedModelFromBundles: [NSBundle allBundles]], which is declared dangerous for just this reason. +Melissa On Mar 25, 2008, at 17:56, Brad Willoughby wrote: When I add /System/Library/Frameworks/CalendarStore.framework to my Leopard Core Data application in XCode 3.0 and click Build Run, I get the following error: The managed object model version used to open the persistent store is incompatible with the one that was used to create the persistent store. This makes no sense to me. I have not touched my data model and can confirm that it has not changed via subversion's svn status. I Googled and checked the cocoa-dev archives, but there's not much out there regarding the Calendar Store framework. Any ideas as to why adding CalendarStore.framework is causing this Core Data error? Cheers, Brad TinyPlanet Software, LLC http://tinyplanetsoftware.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/mjturner%40apple.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
