ObjC SQLite wrapper ???

This message is not archived
 >> Stay informed about: ObjC SQLite wrapper ??? 

Hail

In article
,
Doc O'Leary wrote:

> In article ,
> Ima Pseudonym wrote:
[snipt]
>
> Have you tried contacting the developers? Some of us, and this applies
> not only to SQLite frameworks, maintain up to date versions for internal
> use and only bother to make releases when there is some external reason
> for it. By keeping silent you set up a vicious cycle of developer's not
> releasing updates because they get no feedback, so they get no feedback
> because they haven't been releasing updates.

A good point, but of the three most likely candidates:

- one seems to have moved on (from ObjC) and my Googling found
references on Ruby-themed boards for the last few years. He mentioned
that a new (ObjC) version was in the works and asked for beta testers
back in 2005. That release was never issued; maybe not enough interest
then ?)

- the other two have also moved on and have no visible email addresses.
They do have websites for their new products, but searching their sites
gives no recent references for the sqlite wrapper.

I really do hesitate to drop a line into the feedback bin at their
websites to query an obsolete freeware (i hope product that isn't
even listed any more.

So, I decided to try asking here. If that didn't work then I have three
choices: fuggedaboudit,try to update an old one, start from scratch. I'm
really leaning towards old number 1 -)

Will
 >> Stay informed about: ObjC SQLite wrapper ??? 

In article ,
Ima Pseudonym wrote:

> Hail
>
> I've started thinking about writing a simple database application, in
> which the document's contents will be set and maintained by the user
> (i.e. I can't use XCode to generate the schema at compile time and use a
> managed object solution.
>
> So I started Googling for SQLite wrappers in ObjC and found that there
> aren't any recent versions.

there is an alternative:
<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreDataUtilit
yTutorial/index.html>:

"The task goal of this tutorial is to create a low-level Core
Data-based utility. [...] It shows that although Cocoa bindings can
be used to leverage the functionality in Core Data, it is possible
to use Core Data independently. Moreover, it shows all aspects of
the creation of a Core Data stack, instantiation of managed objects,
and fetching, all without the distraction of a user interface‹it
even shows the creation of a model in code."

Reinder
 >> Stay informed about: ObjC SQLite wrapper ??? 

Hail

In article
,
Reinder Verlinde wrote:

> In article ,
> Ima Pseudonym wrote:
[snipt]
> > I've started thinking about writing a simple database application, in
> > which the document's contents will be set and maintained by the user
> > (i.e. I can't use XCode to generate the schema at compile time and use a
> > managed object solution.
[snipt]
>
> there is an alternative:
> <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreDataUtilit
> yTutorial/index.html>:
>
> "The task goal of this tutorial is to create a low-level Core
> Data-based utility. [...] It shows that although Cocoa bindings can
> be used to leverage the functionality in Core Data, it is possible
> to use Core Data independently. Moreover, it shows all aspects of
> the creation of a Core Data stack, instantiation of managed objects,
> and fetching, all without the distraction of a user interface‹it
> even shows the creation of a model in code."
>
> Reinder

Thanks for the suggestion, I hadn't seen that it was possible to do
that. But it's probably not a good solution for me.

I didn't give enough info in my original note ... I'm playing with the
idea of writing a sort of DIY database application. Sort of two steps
beyond a spreadsheet and two steps behind AppleWorks. Simple data
storage (and, ideally relational links between tables) user-defind
searches and reporting capability.

So, one user may create many databases, and I'd like a cheap, easy
storage solution into which I can add my own metadata, report and sorts.

Will
 >> Stay informed about: ObjC SQLite wrapper ??? 

On 2008-01-27 12:09:11 -0800, Ima Pseudonym said:

> Thanks for the suggestion, I hadn't seen that it was possible to do
> that. But it's probably not a good solution for me.
>
> I didn't give enough info in my original note ... I'm playing with the
> idea of writing a sort of DIY database application. Sort of two steps
> beyond a spreadsheet and two steps behind AppleWorks. Simple data
> storage (and, ideally relational links between tables) user-defind
> searches and reporting capability.

Nothing prevents you from doing this using Core Data.

Specifically, you don't have to design a static data model for an
application using the Xcode design tools. An NSManagedObjectModel is
just an object, like any other object, and it has NSEntityDescription
instances which in turn have NSPropertyDescription instances that
describe a specific model.

Instead of using SQLite directly and reinventing the wheel, as your
users design a particular database you could just generate a model for
them behind the scenes. NSManagedObjectModel supports keyed NSCoding,
so you could even encode the model and stick it in the metadata for the
NSPersistentStore that represents a particular document; that way, each
document would carry the current version of its model with it.

-- Chris
 >> Stay informed about: ObjC SQLite wrapper ??? 

Hail

In article , Chris Hanson
wrote:

> Nothing prevents you from doing this using Core Data.
>
> Specifically, you don't have to design a static data model for an
> application using the Xcode design tools. An NSManagedObjectModel is
> just an object, like any other object, and it has NSEntityDescription
> instances which in turn have NSPropertyDescription instances that
> describe a specific model.
>
> Instead of using SQLite directly and reinventing the wheel, as your
> users design a particular database you could just generate a model for
> them behind the scenes. NSManagedObjectModel supports keyed NSCoding,
> so you could even encode the model and stick it in the metadata for the
> NSPersistentStore that represents a particular document; that way, each
> document would carry the current version of its model with it.


OK thanks. You've pretty much talked me out of the whole project ...

I'm not too experienced in Cocoa yet, and I don't know anything about
SQLite either. Therefore I'm not ready to jump into the middle of a Core
Data project without any background at all in KVO or bindings or the
backing data storage methodology.

I'll take some more time and do more groundwork (i.e. one piece at a
time) for a while until I'm ready for the combined challenge

Thanks to all for the advice.

Will
 >> Stay informed about: ObjC SQLite wrapper ??? 

> On 2008-01-27 12:09:11 -0800, Ima Pseudonym said:
>
> > Thanks for the suggestion, I hadn't seen that it was possible to do
> > that. But it's probably not a good solution for me.
> >
> > I didn't give enough info in my original note ... I'm playing with the
> > idea of writing a sort of DIY database application. Sort of two steps
> > beyond a spreadsheet and two steps behind AppleWorks. Simple data
> > storage (and, ideally relational links between tables) user-defind
> > searches and reporting capability.

The best SQLite Cocoa framework I found was developed by Blackhole Media:

http://www.blackholemedia.com/code/

scroll down to the entry for 'SQLDatabase 0.1'.

The database works fine as planned but it's for SQLite versions before 3.
You'll need to update this for version 3 of SQLite and this is done mostly
by adding a '3' to the end of SQLite function calls. Once you've got the
(included) demo application working, using the framework is trivial.

Simon.
--
http://www.hearsay.demon.co.uk
 >> Stay informed about: ObjC SQLite wrapper ??? 

Hail

In article ,
Simon Slavin
wrote:

>
> The best SQLite Cocoa framework I found was developed by Blackhole Media:
>
> http://www.blackholemedia.com/code/
>
> scroll down to the entry for 'SQLDatabase 0.1'.
>
> The database works fine as planned but it's for SQLite versions before 3.
> You'll need to update this for version 3 of SQLite and this is done mostly
> by adding a '3' to the end of SQLite function calls. Once you've got the
> (included) demo application working, using the framework is trivial.

Thank you, Simon, I found that during the extensive Googling which I did
before asking here.

You may also be interested by QuickLite 1.5.6 at
<http://www.webbotech.com/> which is already adapted to use SQLite 3.2.2.

I had some performance problems when I tried to parachute in the latest
version (3.5.4), though, and I don't know SQLite well enough to
uderstand why

Will
 >> Stay informed about: ObjC SQLite wrapper ???