pyobjc-dev

[Pyobjc-dev] SQLite and PyObjC

[John V. <ve...@co...>]

I'm hoping to write a Cocoa application with PyObjC that uses an sqlite
database.  I will want browse views that show (multilple row) results of a
query, as well as forms for data entry or editing, and output of reports in
pdf format.  I need to develop on Leopard intel, and run on Tiger PPC.
(I've looked at a couple of other approaches, but they each have problems,
and I aesthetically like the idea of PyObjC with Cocoa.  Thanks to the
PyObjC developers!)

I'm probably in way over my head.  But here are a couple of initial
questions:

1.  Which is better to use for the sqlite interface, the Xcode interface to
sqlite, or the Python interface?  If Xcode is better, how the heck can I
find some documentation? Googling or searching in the developer
documentation hasn't gotten me there yet.  Probably because I don't know
the right search words. The amount of Apple documentation is enormous.

Also, some documentation that won't be too hard to translate to use with
PyObjC?

2. For display of tabular query results, is NSTableView the "best" way to
go?   I've had a quick scan of the "Understanding the NSTableView Class,
and a look at one of the examples, and I'm overwhelmed.  I don't need to
edit this in place.  One alternative would appear to be formatting into
columns in Python, and use some form of NSBrowser or NSTextView.

I think I can handle input and edit forms.  If I can convince myself that I
can handle using sqlite in the Model, and some form of browser as a view,
I'll press on!

Thanks,

John Velman

Re: [Pyobjc-dev] SQLite and PyObjC

[John V. <ve...@co...>]

Barry,

Thanks for your response.  Of course, XCode is an IDE, I knew that, but in
my haste  (in the words of H. Clinton) "I said something I knew not to be
true".  I think I should have said something like "the Cocoa Core Data
access to SQLite", which I have seen references to, and which, I presume,
is an Objective C interface to SQLite.

Anyhow, I am writing in PyObjC, so as you suggest, I'll use the python
interface.  Have done C and C++ programming in the past, and suppose I
could learn objective C, but don't want to.  I'm too old (my first
programming language was Fortran II, followed by the assembly language FAP
on an IBM 7090).

Thanks also for your advice on NSTableView.

Best,

John V.

On Sat, Jul 05, 2008 at 08:55:49AM -0700, Barry Wark wrote:
> On Fri, Jul 4, 2008 at 10:16 AM, John Velman <ve...@co...> wrote:
> > I'm hoping to write a Cocoa application with PyObjC that uses an sqlite
> > database.  I will want browse views that show (multilple row) results
> > of a query, as well as forms for data entry or editing, and output of
> > reports in pdf format.  I need to develop on Leopard intel, and run on
> > Tiger PPC. (I've looked at a couple of other approaches, but they each
> > have problems, and I aesthetically like the idea of PyObjC with Cocoa.
> > Thanks to the PyObjC developers!)
> >
> > I'm probably in way over my head.  But here are a couple of initial
> > questions:
> >
> > 1.  Which is better to use for the sqlite interface, the Xcode
> > interface to sqlite, or the Python interface?  If Xcode is better, how
> > the heck can I find some documentation? Googling or searching in the
> > developer documentation hasn't gotten me there yet.  Probably because I
> > don't know the right search words. The amount of Apple documentation is
> > enormous.
> >
> > Also, some documentation that won't be too hard to translate to use
> > with PyObjC?
> 
> When you say Xcode, I assume you mean writing the interface in C or
> Objective-C. Xcode is an IDE, not a programming language or libaray, and
> in fact supports development in several languages including Python. There
> are C and Objective-C interfaces to SQLite, but if you intend to write
> the rest of your application in Python, I would recommend sticking with
> Python for the entire codebase.
> 
> >
> > 2. For display of tabular query results, is NSTableView the "best" way
> > to go?
> 
> Yes.
> 
> I've had a quick scan of the "Understanding the NSTableView Class,
> > and a look at one of the examples, and I'm overwhelmed.  I don't need
> > to edit this in place.  One alternative would appear to be formatting
> > into columns in Python, and use some form of NSBrowser or NSTextView.
> 
> Have a look at the NSTableDataSource Protocol Reference. NSTableViews
> keep a reference to a table data source. The data source supplies the
> approrpirate table data when requested. NSTableViews can also be
> populated via an NSArrayController using Cocoa's bindings technology.
> Given your lack of familiarity with Cocoa technologies, I would recommend
> the first (NSTableDataSource) approach.
> 
> >
> > I think I can handle input and edit forms.  If I can convince myself
> > that I can handle using sqlite in the Model, and some form of browser
> > as a view, I'll press on!
> >
> > Thanks,
> >
> > John Velman
> >
> > -------------------------------------------------------------------------
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source project,
> > along with a healthy diet, reduces your potential for chronic lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> > _______________________________________________ Pyobjc-dev mailing list
> > Pyo...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> >

Re: [Pyobjc-dev] SQLite and PyObjC

[Barry W. <bar...@gm...>]

On Sat, Jul 5, 2008 at 9:17 AM, John Velman <ve...@co...> wrote:
> Barry,
>
> Thanks for your response.  Of course, XCode is an IDE, I knew that, but in
> my haste  (in the words of H. Clinton) "I said something I knew not to be
> true".  I think I should have said something like "the Cocoa Core Data
> access to SQLite", which I have seen references to, and which, I presume,
> is an Objective C interface to SQLite.

No worries. Sorry if my answer came off as pedantic. CoreData is an
object graph management framework that _happens_ to use SQLite as one
of its backing stores. Apple has been very explicit in stating that
you shouldn't rely on the SQLite schema it uses for your own purposes;
it's an implementation detail and may change. As such, CoreData isn't
really appropriate for reading from arbitrary SQLite databases or as a
a way to write data to SQLite databases in a format that you control.
It is a really strong object graph management system and is worth the
time to grok it--just maybe not for this project.

>
> Anyhow, I am writing in PyObjC, so as you suggest, I'll use the python
> interface.  Have done C and C++ programming in the past, and suppose I
> could learn objective C, but don't want to.  I'm too old (my first
> programming language was Fortran II, followed by the assembly language FAP
> on an IBM 7090).

Given your experience, I would expect that you could pick up
Objective-C in less than a day. It's _much_ easier than C++ to grok
(being a much simpler language). If you've come across smalltalk at
all, you'll see many similarities.  Depending on the scope of the
project, you may find that the greater support provided by Xcode
(including gdb and code completion of user defined types) for
Objective-C vs. python outweighs the small cost of learning
Objective-C. Regardless, I would stick to one or the other, if you can
-- debugging across the language boundaries is not well supported by
the available tools.

>
> Thanks also for your advice on NSTableView.

You bet. Feel free to ping me offline if you need any pointers.

>
> Best,
>
> John V.
>
> On Sat, Jul 05, 2008 at 08:55:49AM -0700, Barry Wark wrote:
>> On Fri, Jul 4, 2008 at 10:16 AM, John Velman <ve...@co...> wrote:
>> > I'm hoping to write a Cocoa application with PyObjC that uses an sqlite
>> > database.  I will want browse views that show (multilple row) results
>> > of a query, as well as forms for data entry or editing, and output of
>> > reports in pdf format.  I need to develop on Leopard intel, and run on
>> > Tiger PPC. (I've looked at a couple of other approaches, but they each
>> > have problems, and I aesthetically like the idea of PyObjC with Cocoa.
>> > Thanks to the PyObjC developers!)
>> >
>> > I'm probably in way over my head.  But here are a couple of initial
>> > questions:
>> >
>> > 1.  Which is better to use for the sqlite interface, the Xcode
>> > interface to sqlite, or the Python interface?  If Xcode is better, how
>> > the heck can I find some documentation? Googling or searching in the
>> > developer documentation hasn't gotten me there yet.  Probably because I
>> > don't know the right search words. The amount of Apple documentation is
>> > enormous.
>> >
>> > Also, some documentation that won't be too hard to translate to use
>> > with PyObjC?
>>
>> When you say Xcode, I assume you mean writing the interface in C or
>> Objective-C. Xcode is an IDE, not a programming language or libaray, and
>> in fact supports development in several languages including Python. There
>> are C and Objective-C interfaces to SQLite, but if you intend to write
>> the rest of your application in Python, I would recommend sticking with
>> Python for the entire codebase.
>>
>> >
>> > 2. For display of tabular query results, is NSTableView the "best" way
>> > to go?
>>
>> Yes.
>>
>> I've had a quick scan of the "Understanding the NSTableView Class,
>> > and a look at one of the examples, and I'm overwhelmed.  I don't need
>> > to edit this in place.  One alternative would appear to be formatting
>> > into columns in Python, and use some form of NSBrowser or NSTextView.
>>
>> Have a look at the NSTableDataSource Protocol Reference. NSTableViews
>> keep a reference to a table data source. The data source supplies the
>> approrpirate table data when requested. NSTableViews can also be
>> populated via an NSArrayController using Cocoa's bindings technology.
>> Given your lack of familiarity with Cocoa technologies, I would recommend
>> the first (NSTableDataSource) approach.
>>
>> >
>> > I think I can handle input and edit forms.  If I can convince myself
>> > that I can handle using sqlite in the Model, and some form of browser
>> > as a view, I'll press on!
>> >
>> > Thanks,
>> >
>> > John Velman
>> >
>> > -------------------------------------------------------------------------
>> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> > Studies have shown that voting for your favorite open source project,
>> > along with a healthy diet, reduces your potential for chronic lameness
>> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> > _______________________________________________ Pyobjc-dev mailing list
>> > Pyo...@li...
>> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>> >
>

Re: [Pyobjc-dev] SQLite and PyObjC

[Samantha A. <sja...@ma...>]

On Jul 5, 2008, at 9:17 AM, John Velman wrote:

> Barry,
>
> Thanks for your response.  Of course, XCode is an IDE, I knew that,  
> but in
> my haste  (in the words of H. Clinton) "I said something I knew not  
> to be
> true".  I think I should have said something like "the Cocoa Core Data
> access to SQLite", which I have seen references to, and which, I  
> presume,
> is an Objective C interface to SQLite.
>
> Anyhow, I am writing in PyObjC, so as you suggest, I'll use the python
> interface.

Core Data is a general "document" / application data store Cocoa  
framework.  It covers both flat flie, XML and sqlite stores.   Its API  
is the same on all.  Among other things this means that some  
capabilities of a RDBMS are not exposed by Core Data.  Core Data is  
more or less an ORM or rather an OSM where the S is more generic store  
than just relational.   As such it imposes its own layout to the  
underlying sqlite tables to support a subset of object persistence.    
I would not recommend that you programs attempt to grok and correctly  
handle that layout directly.  Instead for a Core Data database you  
should use the Core Data framework from pyobjc.   There are some  
shortcuts that get around some of the Xcode and application centric  
docs on Core Data.  For one thing there is a "MOM" file for any Core  
Data database and Core Data APIs that you can use to dynamically read  
a MOM, parse out the types of Entities and Relationships and then go  
from there to read any data in the Core Data db and show it any way  
you want.

Hope that helps.

- samantha



> Have done C and C++ programming in the past, and suppose I
> could learn objective C, but don't want to.  I'm too old (my first
> programming language was Fortran II, followed by the assembly  
> language FAP
> on an IBM 7090).
>
> Thanks also for your advice on NSTableView.
>
> Best,
>
> John V.
>
> On Sat, Jul 05, 2008 at 08:55:49AM -0700, Barry Wark wrote:
>> On Fri, Jul 4, 2008 at 10:16 AM, John Velman <ve...@co...> wrote:
>>> I'm hoping to write a Cocoa application with PyObjC that uses an  
>>> sqlite
>>> database.  I will want browse views that show (multilple row)  
>>> results
>>> of a query, as well as forms for data entry or editing, and output  
>>> of
>>> reports in pdf format.  I need to develop on Leopard intel, and  
>>> run on
>>> Tiger PPC. (I've looked at a couple of other approaches, but they  
>>> each
>>> have problems, and I aesthetically like the idea of PyObjC with  
>>> Cocoa.
>>> Thanks to the PyObjC developers!)
>>>
>>> I'm probably in way over my head.  But here are a couple of initial
>>> questions:
>>>
>>> 1.  Which is better to use for the sqlite interface, the Xcode
>>> interface to sqlite, or the Python interface?  If Xcode is better,  
>>> how
>>> the heck can I find some documentation? Googling or searching in the
>>> developer documentation hasn't gotten me there yet.  Probably  
>>> because I
>>> don't know the right search words. The amount of Apple  
>>> documentation is
>>> enormous.
>>>
>>> Also, some documentation that won't be too hard to translate to use
>>> with PyObjC?
>>
>> When you say Xcode, I assume you mean writing the interface in C or
>> Objective-C. Xcode is an IDE, not a programming language or  
>> libaray, and
>> in fact supports development in several languages including Python.  
>> There
>> are C and Objective-C interfaces to SQLite, but if you intend to  
>> write
>> the rest of your application in Python, I would recommend sticking  
>> with
>> Python for the entire codebase.
>>
>>>
>>> 2. For display of tabular query results, is NSTableView the "best"  
>>> way
>>> to go?
>>
>> Yes.
>>
>> I've had a quick scan of the "Understanding the NSTableView Class,
>>> and a look at one of the examples, and I'm overwhelmed.  I don't  
>>> need
>>> to edit this in place.  One alternative would appear to be  
>>> formatting
>>> into columns in Python, and use some form of NSBrowser or  
>>> NSTextView.
>>
>> Have a look at the NSTableDataSource Protocol Reference. NSTableViews
>> keep a reference to a table data source. The data source supplies the
>> approrpirate table data when requested. NSTableViews can also be
>> populated via an NSArrayController using Cocoa's bindings technology.
>> Given your lack of familiarity with Cocoa technologies, I would  
>> recommend
>> the first (NSTableDataSource) approach.
>>
>>>
>>> I think I can handle input and edit forms.  If I can convince myself
>>> that I can handle using sqlite in the Model, and some form of  
>>> browser
>>> as a view, I'll press on!
>>>
>>> Thanks,
>>>
>>> John Velman
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source  
>>> project,
>>> along with a healthy diet, reduces your potential for chronic  
>>> lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________ Pyobjc-dev mailing  
>>> list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] SQLite and PyObjC

[John V. <ve...@co...>]

On Sat, Jul 05, 2008 at 01:42:04PM -0700, Samantha Atkins wrote:
>
 --snip--
>
> Core Data is a general "document" / application data store Cocoa framework. 
>  It covers both flat flie, XML and sqlite stores.   Its API is the same on 
> all.  Among other things this means that some capabilities of a RDBMS are 
> not exposed by Core Data.  Core Data is more or less an ORM or rather an 
> OSM where the S is more generic store than just relational.   As such it 
> imposes its own layout to the underlying sqlite tables to support a subset 
> of object persistence.   I would not recommend that you programs attempt to 
> grok and correctly handle that layout directly.  Instead for a Core Data 
> database you should use the Core Data framework from pyobjc.   There are 
> some shortcuts that get around some of the Xcode and application centric 
> docs on Core Data.  For one thing there is a "MOM" file for any Core Data 
> database and Core Data APIs that you can use to dynamically read a MOM, 
> parse out the types of Entities and Relationships and then go from there to 
> read any data in the Core Data db and show it any way you want.
>
> Hope that helps.

Thanks, Samantha. This is a help.

Best,

John V.

Re: [Pyobjc-dev] SQLite and PyObjC

[David B. <db3...@gm...>]

John Velman <ve...@co...> writes:

> 1.  Which is better to use for the sqlite interface, the Xcode interface to
> sqlite, or the Python interface?  If Xcode is better, how the heck can I
> find some documentation? Googling or searching in the developer
> documentation hasn't gotten me there yet.  Probably because I don't know
> the right search words. The amount of Apple documentation is enormous.

Personally I use SQLAlchemy with a sqlite back-end - e.g., stay
completely on the Python side of the equation for data management.
For my application I didn't need any of the ORM features, so I'm just
using the SQL generation layer of SQLAlchemy, but it's great for that.

> 2. For display of tabular query results, is NSTableView the "best" way to
> go?   I've had a quick scan of the "Understanding the NSTableView Class,
> and a look at one of the examples, and I'm overwhelmed.  I don't need to
> edit this in place.  One alternative would appear to be formatting into
> columns in Python, and use some form of NSBrowser or NSTextView.

NSTableView is definitely my workhorse for presenting tabular
information, even if only a single column.  You just get too much
behavior for free not to use it IMO.

In terms of controlling the data flow, I've actually used multiple
methods:

First, I started out enamoured with data bindings, and used them a
lot, even for an array source to a data controller driving an
NSTableView.

Re-assigning the entire array (to trigger the automatic PyObjC binding
update) was sometimes a pain, particularly when I had other state in
the array I wanted to keep, so in some cases I started controlling the
notification myself, permitting mutation in place of the data - e.g.,
I called willChangeValueForKey_, then modified, then called
didChangeValueForKey_).

But as I went on, I found that although there was slightly more setup,
creating an appropriate data source for the NSTableView was more
flexible, particularly as the data changed, or if it was being
retrieved incrementally, such as from the network or database.

I still have a mixture of approaches in the main application I used
this with, but if I were starting over, I'd probably use bindings for
simple text fields and status information, but stick with data sources
for the major table views.

-- David