Honestly I am surprised that apple has not adopted one of the OSS database
engines as a standard db in osx and implemented core data on top of it for
multi user implementations.
If for no other reason than to shoot at Microsoft over the mssql as part of the
file system debacle
Andy 'Dru' Sator
I looked at it pretty hard, but in the end I went with a traditional RDBMS,
largely for the eventual need to expose the interface to external reporting
tools, that as a rule don't talk custom interfaces. Admittedly, I borrowed
some concepts though.
Design wise the 'server' in my configuration
On Apr 12, 2010, at 11:08 AM, Jens Alfke wrote:
The @*$& listserv is stripping the HTML from messages, so the links
in my previous post got lost. (I guess hyperlinking is too
newfangled a concept for Mailman?)
I think you meant to say "The listserv is sparing us from the %...@ing
atrocit
The @*$& listserv is stripping the HTML from messages, so the links in
my previous post got lost. (I guess hyperlinking is too newfangled a
concept for Mailman?)
CouchDB: http://couchdb.apache.org
Ubuntu DesktopCouch: http://www.freedesktop.org/wiki/Specifications/desktopcouch
—Jens_
On Apr 12, 2010, at 10:54 AM, Dru Satori wrote:
One application that can be used standalone, or always on multi-user
or with multiple disconnected users synchronizing data when peered.
Complex? You have no idea. But in the design process, many
decisions had to be made, that meant archit
Another consideration is:
Is this a project that could ever need a multi-user or networked data engine?
If the above answer is yes, then CoreData is probably a bad option (though
Marko's excellent BaseTen for PostgreSQL might be an option in that case), as
the options for migrating Managed Ob
On 12 Apr 2010, at 17:33, Jens Alfke wrote:
> There are also other data storage libraries that have a simpler data model
> than sqlite (they’re like on-disk NSDictionaries) so they’re a bit simpler to
> use and can potentially run faster. Tokyo Cabinet seems like the main
> contender in that ar
On Apr 12, 2010, at 7:36 AM, Billy Flatman wrote:
> Is it possible to get core data data models to save differently, one for a
> document save which for example might be an XML format, and one into the
> applications bundle as an SQLite file?
> That way when a document is saved the main databas
Hi Billy
> Is it possible to get core data data models to save differently, one for a
> document save which for example might be an XML format, and one into the
> applications bundle as an SQLite file?
>
> That way when a document is saved the main database won't be duplicated, just
> the docu
Hi Samuel,
Is it possible to get core data data models to save differently, one for a
document save which for example might be an XML format, and one into the
applications bundle as an SQLite file?
That way when a document is saved the main database won't be duplicated, just
the document speci
So long as the application is single user, core data or sqlite are both
excellent options. I personally prefer sqlite, as I find it easier to work
with than core data. The problem I have with core data is that it's usage is
so tightly wound to the managed object interface, that is can be diff
Dear Billy,
It might depend on whether you want to remain cross platform or not.
Also, if your requirements are very limited, CoreData might be considered
overkill.
On the other hand, CoreData has great integration with NSDocument type
applications and Cocoa UIs.
Kind regards,
Samuel
On 13/0
> I'm trying to find the best approach to data storage with a cocoa application.
> I've got my application working and saving document specific data to a file,
> but I also need a larger data file of persistent data, that shouldn't be
> duplicated. I'm considering imbedding an SQLite database int
Hi all,
I'm trying to find the best approach to data storage with a cocoa application.
I've got my application working and saving document specific data to a file,
but I also need a larger data file of persistent data, that shouldn't be
duplicated. I'm considering imbedding an SQLite database in
14 matches
Mail list logo
