Re: [ANN] Release: NanoStore 1.0 for Mac and iOS
Hi Chris, On 23/09/2010, at 04:27, Chris Hanson wrote: > On Sep 22, 2010, at 11:39 PM, Tito Ciuro wrote: > >> I believe (please correct me if I'm wrong) that Core Data stores the data >> atomically for both, XML and binary formats. That, if I'm not mistaken >> requires the datafile to be read in memory. Not so with NanoStore: > > Not really so with Core Data either. > > Core Data has the concept of both atomic and non-atomic persistent stores. > > Core Data’s binary and XML persistent stores are atomic, so they are read and > written like documents (all at once). Developers can also create your own > kinds of atomic persistent stores by subclassing NSAtomicStore. (Also, the > XML persistent store is not available on iOS, only on Mac OS X.) > > Core Data’s SQLite persistent store is quite explicitly not atomic: It uses > transactions against SQLite. The entire persistent store does not need to be > read into memory, only the data requested; the entire persistent store is not > written upon a save, only the data changed. > > -- Chris As I mentioned to Thomas, I left part of the sentence out, so thanks for clarifying this. What I meant was precisely what you have written so eloquently. NanoStore is also explicitly not atomic: It uses transactions against SQLite as well storing and indexing the dictionaries. Thanks Chris, -- Tito___ 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: [ANN] Release: NanoStore 1.0 for Mac and iOS
Hi Thomas, On 23/09/2010, at 04:19, Thomas Davie wrote: > > On 23 Sep 2010, at 07:39, Tito Ciuro wrote: > >> Hm. That would be discussed better on a White Paper or similar. There are >> countless tutorials and documents about Core Data already. What I can do >> however is to provide a small example to illustrate how NanoStore works. >> >> I believe (please correct me if I'm wrong) that Core Data stores the data >> atomically for both, XML and binary formats. That, if I'm not mistaken >> requires the datafile to be read in memory. > > That's incorrect, CoreData gives you the choice of XML, binary or SQLite > backends. When using the SQLite one it reads the data lazily. I was thinking about the XML option (binary as well) and didn't finish the sentence, leaving SQLite behind. Yes, Core Data offers three backends. Thanks for the correction, -- Tito ___ 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: [ANN] Release: NanoStore 1.0 for Mac and iOS
On 2010 Sep 22, at 22:15, Thomas Davie wrote: > some of the differences between using this or using CoreData to achieve a > similar thing? An important feature of Core Data is support for Undo, although it is raw and still takes some doing to beat Undo grouping and Undo action names into submission. ___ 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: [ANN] Release: NanoStore 1.0 for Mac and iOS
On Sep 22, 2010, at 11:39 PM, Tito Ciuro wrote: > I believe (please correct me if I'm wrong) that Core Data stores the data > atomically for both, XML and binary formats. That, if I'm not mistaken > requires the datafile to be read in memory. Not so with NanoStore: Not really so with Core Data either. Core Data has the concept of both atomic and non-atomic persistent stores. Core Data’s binary and XML persistent stores are atomic, so they are read and written like documents (all at once). Developers can also create your own kinds of atomic persistent stores by subclassing NSAtomicStore. (Also, the XML persistent store is not available on iOS, only on Mac OS X.) Core Data’s SQLite persistent store is quite explicitly not atomic: It uses transactions against SQLite. The entire persistent store does not need to be read into memory, only the data requested; the entire persistent store is not written upon a save, only the data changed. -- Chris ___ 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: [ANN] Release: NanoStore 1.0 for Mac and iOS
On 23 Sep 2010, at 07:39, Tito Ciuro wrote: > Hm. That would be discussed better on a White Paper or similar. There are > countless tutorials and documents about Core Data already. What I can do > however is to provide a small example to illustrate how NanoStore works. > > I believe (please correct me if I'm wrong) that Core Data stores the data > atomically for both, XML and binary formats. That, if I'm not mistaken > requires the datafile to be read in memory. That's incorrect, CoreData gives you the choice of XML, binary or SQLite backends. When using the SQLite one it reads the data lazily. > Not so with NanoStore: the SQLite database is the storage system and the API > stores and retrieves dictionaries. Another strong point is that you can store > whatever you want: from the developer's perspective, there is no schema, so > objects of different "weight" or complexity can be stored with ease and > retrieved back verbatim. That's certainly a neat trick, I can imagine that lets you get started with this a lot faster than with CoreData. > Now... I like Core Data. I really do. But some times I get the feeling that > it's too heavy for simple tasks. Plus, making CD work requires some reading, > while NanoStore requires a fraction of the time to get it working. I believe > that many developers will welcome this addition, as they will be able to > concentrate their effort on other parts of their app. In essence, I designed > NanoStore to be simple, relatively powerful and fast, while demanding a > minimum effort from the developer. Time will tell if I'm wrong :-) Sounds like a neat middle ground, I'll give it a go some time soon! Bob ___ 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: [ANN] Release: NanoStore 1.0 for Mac and iOS
Hi Thomas, On 23/09/2010, at 02:15, Thomas Davie wrote: > > On 23 Sep 2010, at 03:51, Tito Ciuro wrote: >> >> Today, Webbo is pleased to announce the release of NanoStore: >> >> http://sourceforge.net/projects/nanostore/ >> >> NanoStore is a Cocoa wrapper for SQLite, a C library that implements an >> embeddable SQL database engine. >> >> With NanoStore, you store data using a dictionary of any depth. The >> developer can decide what to store on the fly, unlike other systems that >> require the developer to design a schema. With NanoStore just build your >> dictionary and store it. That's all there is to it! Every data element in >> the dictionary is indexed (except BLOBs) so there's no need to keep a list >> of indexed separately. You can disable indexing, import your data in batch >> mode, save it and then reindex at once, which is quite efficient. For even >> better performance, all I/O can be performed in memory and save the new >> database to disk at once, which is even faster. And if you feel adventurous, >> you can even do that in Fast mode and save extra SQLite processing. > > Sounds like fun! Can you explain some of the differences between using this > or using CoreData to achieve a similar thing? Hm. That would be discussed better on a White Paper or similar. There are countless tutorials and documents about Core Data already. What I can do however is to provide a small example to illustrate how NanoStore works. I believe (please correct me if I'm wrong) that Core Data stores the data atomically for both, XML and binary formats. That, if I'm not mistaken requires the datafile to be read in memory. Not so with NanoStore: the SQLite database is the storage system and the API stores and retrieves dictionaries. Another strong point is that you can store whatever you want: from the developer's perspective, there is no schema, so objects of different "weight" or complexity can be stored with ease and retrieved back verbatim. Now... I like Core Data. I really do. But some times I get the feeling that it's too heavy for simple tasks. Plus, making CD work requires some reading, while NanoStore requires a fraction of the time to get it working. I believe that many developers will welcome this addition, as they will be able to concentrate their effort on other parts of their app. In essence, I designed NanoStore to be simple, relatively powerful and fast, while demanding a minimum effort from the developer. Time will tell if I'm wrong :-) Regards, -- Tito ___ 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: [ANN] Release: NanoStore 1.0 for Mac and iOS
On 23 Sep 2010, at 03:51, Tito Ciuro wrote: > > Today, Webbo is pleased to announce the release of NanoStore: > > http://sourceforge.net/projects/nanostore/ > > NanoStore is a Cocoa wrapper for SQLite, a C library that implements an > embeddable SQL database engine. > > With NanoStore, you store data using a dictionary of any depth. The developer > can decide what to store on the fly, unlike other systems that require the > developer to design a schema. With NanoStore just build your dictionary and > store it. That's all there is to it! Every data element in the dictionary is > indexed (except BLOBs) so there's no need to keep a list of indexed > separately. You can disable indexing, import your data in batch mode, save it > and then reindex at once, which is quite efficient. For even better > performance, all I/O can be performed in memory and save the new database to > disk at once, which is even faster. And if you feel adventurous, you can even > do that in Fast mode and save extra SQLite processing. Sounds like fun! Can you explain some of the differences between using this or using CoreData to achieve a similar thing? Thanks Bob ___ 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
[ANN] Release: NanoStore 1.0 for Mac and iOS
NanoStore 1.0 © Webbo, L.L.C., 2010. All rights reserved. September 21, 2010 Today, Webbo is pleased to announce the release of NanoStore: http://sourceforge.net/projects/nanostore/ NanoStore is a Cocoa wrapper for SQLite, a C library that implements an embeddable SQL database engine. With NanoStore, you store data using a dictionary of any depth. The developer can decide what to store on the fly, unlike other systems that require the developer to design a schema. With NanoStore just build your dictionary and store it. That's all there is to it! Every data element in the dictionary is indexed (except BLOBs) so there's no need to keep a list of indexed separately. You can disable indexing, import your data in batch mode, save it and then reindex at once, which is quite efficient. For even better performance, all I/O can be performed in memory and save the new database to disk at once, which is even faster. And if you feel adventurous, you can even do that in Fast mode and save extra SQLite processing. All these variations come with pros and cons, sure... but you have a choice. You can decide what's best *for you* and map a strategy to *your* model as there accessors available for most SQLite settings and pragmas that will allow you to tune it to your liking. The list of classes include: NSFNanoStore NSFNanoExpression NSFNanoSearch NSFNanoResult You also have full access to the sqlite3* handle, in case you need it (hey... you're a developer right?) In addition, the NanoStore project includes: - Unit tests - An iOS plain-vanilla app to demonstrate how easy it is to embed NanoStore in your project Enjoy! -- Tito * Tito Ciuro R&D Group, Webbo, L.L.C. ___ 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
