On Apr 8, 2014, at 5:31 PM, BareFeetWare
wrote:
>> One option is to use SQLite. I've been putting together an open source
>> "BFWQuery" library to hopefully simplify the whole thing, by letting you
>> treat a database query just like an array of dictionaries. It uses FMDB
>> (thanks Gus).
>>
On Apr 8, 2014, at 4:20 PM, Jens Alfke wrote:
>
> I’m not a big fan of Core Data, but if you’ve worked with it before I suspect
> you’ll find it more efficient to use it for this than to roll your own.
Even if you haven't worked with it before, it'll still probably wind up being
more efficient
On Apr 9, 2014, at 07:49 , Jens Alfke wrote:
> You can always write some code to export the database to XML for such
> purposes.
> But for regular storage, SQLite, or even a binary-format flat file, is going
> to be a lot more efficient than XML. (Assuming you have a large data set.)
Oh, I ab
On Apr 8, 2014, at 10:07 PM, Rick Mann wrote:
> Well, if I were to do this, one of the reasons would be to create a text
> representation that could be easily diffed. I took a look at Core Data's XML
> format, and while necessarily verbose, it would work pretty well, until the
> schema change
On Apr 8, 2014, at 18:09 , Graham Cox wrote:
>
> On 9 Apr 2014, at 8:13 am, Rick Mann wrote:
>
>> As I write this, I realize that I can't just keep a whole document in
>> memory; the library (which would be a collection of separate files on disk,
>> but presented as a unified collection of
On Apr 8, 2014, at 5:31 PM, BareFeetWare
wrote:
> for (NSDictionary* rowDict in query.resultArray) {
> NSLog(@"%@: (%@, %@)", rowDict[@"Name"], rowDict[@"Latitude"],
> rowDict[@"Longitude"]);
> }
>
> Or to just get row 3's value for Name:
>
> query.resultArray[3][@"Name"];
Watch out:
On 9 Apr 2014, at 8:13 am, Rick Mann wrote:
> As I write this, I realize that I can't just keep a whole document in memory;
> the library (which would be a collection of separate files on disk, but
> presented as a unified collection of content in the UI) could be very large
> and I'd rather
Hi Rick,
One option is to use SQLite. I've been putting together an open source
"BFWQuery" library to hopefully simplify the whole thing, by letting you treat
a database query just like an array of dictionaries. It uses FMDB (thanks Gus).
eg: query.resultArray[row][columnName]
Here is an examp
that’s how i should do it. particularly, if you have complicated selections
that me must be undone/redone you’ll find you have excellent control, as well.
On Apr 8, 2014, at 7:46 PM, Rick Mann wrote:
>
> On Apr 8, 2014, at 16:41 , edward taffel wrote:
>
>> moving history into your model wil
On Apr 8, 2014, at 16:41 , edward taffel wrote:
> moving history into your model will better facilitate portability [in case
> you’re thinking in this direction].
Is that how that works? The history ends up in my model?
--
Rick
signature.asc
Description: Message signed with OpenPGP usin
using NSDocument w/ autosaves is a great way to go—lots of bang for your buck!
xml could open possibilities in terms of web potential.
moving history into your model will better facilitate portability [in case
you’re thinking in this direction].
all good things for a cad app.
On Apr 8, 2014, at
On Apr 8, 2014, at 3:13 PM, Rick Mann wrote:
> As I write this, I realize that I can't just keep a whole document in memory;
> the library (which would be a collection of separate files on disk, but
> presented as a unified collection of content in the UI) could be very large
> and I'd rather
On Tue, 8 Apr 2014 15:47:21 -0700, Rick Mann said:
>Oh, maybe you're right; that would work if I just coded up my class's
>property as "id", wouldn't it? Don't know why I thought that wouldn't work.
For example, we have a class that represents a 4x4 matrix. It conforms to
NSCoding to serialize
On Apr 8, 2014, at 15:42 , Sean McBride wrote:
> On Tue, 8 Apr 2014 15:24:19 -0700, Rick Mann said:
>
>> but Core Data doesn't let me have an entity attribute of type id, AFAIK
>
> Sure you can, that's what 'transformable' attributes are. Your custom object
> would need to be able to seriali
On Tue, 8 Apr 2014 15:24:19 -0700, Rick Mann said:
>but Core Data doesn't let me have an entity attribute of type id, AFAIK
Sure you can, that's what 'transformable' attributes are. Your custom object
would need to be able to serialize/deserialize itself via NSCoding to be able
to persist itse
Well, one of the issues is the data types. It's a bit clunky, but workable.
There's one type of entity I want to create, a "Properties" table that maps
strings to arbitrary value types. This would be trivial if I managed it myself,
but Core Data doesn't let me have an entity attribute of type id
Depends. Why are you “fighting” Core Data?
Mike
On Apr 8, 2014, 3:13:12 PM, Rick Mann wrote: This may
prove to be an unproductive question to pose, so I apologize in advance.
I'm generally a big fan of Core Data, but I'm developing a moderately
complicated CAD app with libraries and desig
17 matches
Mail list logo
