Golden rule: don't upgrade until first sevice pack. Release date set by management, so you have to ship with whatever bugs are left. But patch is usually developed with more timely approach.
You’d think Apple would at least want to take care of any visual inconsistencies, specially in one of the major features which are touted as the big incentives for upgrading. There are still some UI elements here and there which are out of place in Dark Mode at best, or almost illegible at worst.
Such lax approach to UX polish has traditionally been associated with Microsoft, not Apple.
I reported (and had Apple engineers come to meet us) a severe bug (found and showed the engineers the single line of code in the public source code) in OSX 10.4’s wifi stack, wasn’t fixed until 10.8. Literally a single line of code.
Largely agree but if everyone did this, bugs would not surface... for this to work, some people ought to upgrade and others hang back.. which is already what happens anyway...
Sure they would. You can avoid upgrading a device you depend on, while installing the latest beta and .0 OS releases on a test system or partition. That's what most developers I know do.
Core Data is basically a layer over SQLite that turns it into an object graph database.
External data storage lets you offload large binary data from being stored in the SQLite database without changing how you access that data from objects in the graph.
An example might be if you're creating a photo library. Rather than storing the actual photos as say BLOB data in SQLite, you can tell Core Data to transparently store it as an external file. It then basically stores the filename and some metadata in SQLite instead, keeping the SQLite database small without changing the Core Data API to access the data.
Core Data is an object persistence framework for iOS that essentially wraps around SQL. It looks like it’s losing data when the external storage option is enabled.
I doubt it. The data is stored externally in the filesystem and referenced in the SQLite database. I guess something happens in the filesystem or during every second storing process, so that the metadata references become out of sync.
I'd guess it's because someone isn't accessing it from a single thread, or isn't following the lifecycle requirements for storing data in an asynchronous datastore.
You absolutely have to wait for the completion event for a write before issuing another write to the same key for example.
CoreData has the option to store blobs as flat files, outside the SQLite DB. The DB only contains the metadata to locate the files. Looks like they're messing up these external files.
And I guess there's no way to create a transaction between the file system and the sqlite db. I've often thought that would be a useful feature sometimes - maybe something in the sqlite API could write your file, and then commit when verified on the filesystem.
What are the foundationDB guys doing ? After they got bought I was hoping so much that ios would get a brand new storage technology that really works well using their famous testing environment.
I don't know what's wrong with core data because throughout the years it's been one of those technology that are both unconvenient AND regularely unreliable.
