> > But you already have pandas.read_sql_query. While that function
> > isn't really what I'd call simple, the complexity afaict -- dates,
> > floats, and chunks -- can be laid at Python's feet.
>
> I use R rather than python but the problem of dates is significant and
> I assume the same proble
On Mon, Feb 1, 2016 at 8:27 AM, Keith Medcalf wrote:
>
>> > But you already have pandas.read_sql_query. While that function
>> > isn't really what I'd call simple, the complexity afaict -- dates,
>> > floats, and chunks -- can be laid at Python's feet.
>>
>> I use R rather than python but the pro
> > There is no impedence mismatch. Simply inadequate wattage by the
> person(s) solving the problem. As I said, this problem has been solved
> with SQLite and Python for a decade. So I would suggest the problem is
> that the wattage was so low, the lights were completely out.
> The impedence
> It is a standard feature of pysqlite2 (the sqlite3 library shipped with
> Python). I am quite sure you can read the documentation just as well as I
> can copy and paste it. In short, you can use anything you like as the data
> type in sqlite. You could specify that some column contains:
>
>
At the command line interface (CLI) in SQLite
(and most SQL implementations) is an interpreted
set at a time language with implicit loops.
Efficient low level languages (such as C) process data
a record at a time and the existing API is appropriate
for them.
Object Oriented Interactive Languages
On Jan 7, 2016, at 5:22 PM, Jim Callahan
wrote:
>
> I believe R has remarkably good interface packages for SQLite
That?s the appropriate level: the high-level language's DB access layer should
map the low-level C record-at-a-time API to an appropriate language-level
abstraction.
R almost for
On 2016-01-07 4:55 PM, Warren Young wrote:
> 2. There is no ?preview? mechanism. That is, you can?t bind some parameters
> to a prepared query string and then get the resulting SQL because SQLite
> substitutes the values into the query at a layer below the SQL parser. This
> means that if you
I personally wish the reverse. I wish that these interpreted language
engines would incorporate the SQLite code directly into their own existence
to avoid having to write wrappers to begin with, except for those wrappers
where their method name is "DatabaseOpen" and I prefer "OpenDatabase".
SQLit
On Jan 7, 2016, at 6:04 PM, Darren Duncan wrote:
>
> On 2016-01-07 4:55 PM, Warren Young wrote:
>> 2. There is no ?preview? mechanism.
>
> The current method of binding is correct. All we really need is that the
> debug logging layer include both the SQL of the prepared statement AND a list
>
On 8 Jan 2016, at 12:22am, Jim Callahan
wrote:
> The existing SQLite APIs are correct, but hard to use in the
> sense that creating an interface from an OOIL language is more involved
> than just "wrapping" one by one a set of functions. What I am proposing is
> a second set of APIs that when t
Perhaps we misunderstand each other here.
I interpreted your request as if current systems' error outputs at execute time
were printing out the problematic SQL statement with placeholder names as
originally prepared, and you wanted the error outputs to have the placeholders
substituted with lit
Stephen,
What you are arguing for (no shared libraries) is bad old days where one had to
recompile their programming language to add support for a DBMS, rather than the
DBMS support being a separately installable library that one could choose to
install or not or upgrade semi-independently or n
This is how R works too. That is the RSQLite package that gives
access to SQLite includes SQLite itself right in the package itself so
one need not separately install SQLite.
Also RSQlite uses the R DBI package which defines connections as
classes which are subclassed by the various database pack
On 2016/01/08 9:51 AM, Darren Duncan wrote:
> Stephen,
>
> What you are arguing for (no shared libraries) is bad old days where
> one had to recompile their programming language to add support for a
> DBMS, rather than the DBMS support being a separately installable
> library that one could ch
Because this list supports many different things, not just SQLite
downloaded from sqlite.org, maybe I'm off target with my interpretation of
these wishlists.
I'm not arguing about pros and cons of shared libraries directly. My
comments were made from a tired guy who started the day early, was bus
On Fri, Jan 8, 2016 at 10:54 AM, R Smith wrote:
>
> I can't agree more - and to add, while I can sympathize with the point, I
> absolutely love SQLite, but the amount of projects I have made without
> SQLite far outweighs those containing it (on all platforms). I would like
> it to remain optiona
On Jan 8, 2016, at 12:39 AM, Darren Duncan wrote:
>
> I interpreted your request as if current systems' error outputs at execute
> time were printing out the problematic SQL statement with placeholder names
> as originally prepared, and you wanted the error outputs to have the
> placeholders s
On 2016-01-08 8:08 AM, Stephen Chrzanowski wrote:
> For the record, *I* personally prefer trying to get all essential resources
> built directly into my final output (For SQLite, default database
> structures, SQLite strings, and maybe that one day, SQLite itself), that
> way I'm in control of what
Okay, I think this clears some things up.
On 2016-01-08 11:36 AM, Warren Young wrote:
> On Jan 8, 2016, at 12:39 AM, Darren Duncan wrote:
>>
>> I interpreted your request as if current systems' error outputs at execute
>> time were printing out the problematic SQL statement with placeholder name
-Original Message-
From: sqlite-users-bounces at mailinglists.sqlite.org
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Darren Duncan
Sent: Saturday, 9 January 2016 9:22 AM
To: SQLite mailing list
Subject: Re: [sqlite] Wish List for 2016: High Level API for Object Oriented
Today, I found a Python package, "JayDeBeApi" that accesses SQLite via JDBC
rather than directly through the C language Call Level Interface (CLI).
https://github.com/baztian/jaydebeapi/blob/master/README.rst
This might provide the object oriented interface I have been looking for!
Has anyone trie
On Thu, 28 Jan 2016 16:47:40 -0500
Jim Callahan wrote:
> I am hopeful this new JDBC based interface will provide as
> satisfactory high level channel between SQLite3 and Python.
As someone who's written a couple of OO DBMS libraries and uses the
Python SQLIte module, I wonder what you're hoping
On Sat, 30 Jan 2016 14:56:15 -0500
"James K. Lowden" wrote:
> On Thu, 28 Jan 2016 16:47:40 -0500
> Jim Callahan wrote:
>
> > I am hopeful this new JDBC based interface will provide as
> > satisfactory high level channel between SQLite3 and Python.
>
> As someone who's written a couple of OO DB
On 30 Jan 2016, at 8:13pm, Yannick Duch?ne wrote:
> In my opinion (which some others share), OO is a bag of miscellaneous things
> which are better tools and better understood when accosted individually. Just
> trying to define what OO is, shows it: is this about late binding? (if it is,
> th
I am not interested in a complete ORM; what I am interested is when the
object-oriented language supports a SQL-R-like object. In R, the object is
called a data.frame and the package "Pandas" supplies a similar data frame
object to Python.
https://pypi.python.org/pypi/pandas/0.10.0/
R as I have me
On Sat, 30 Jan 2016 20:50:17 -0500
Jim Callahan wrote:
> I am not interested in a complete ORM; what I am interested is when the
> object-oriented language supports a SQL-R-like object. In R, the object is
> called a data.frame and the package "Pandas" supplies a similar data frame
> object to Py
On Sat, 30 Jan 2016 23:03:29 +
Simon Slavin wrote:
>
> On 30 Jan 2016, at 8:13pm, Yannick Duch?ne
> wrote:
>
> > In my opinion (which some others share), OO is a bag of miscellaneous
> > things which are better tools and better understood when accosted
> > individually. Just trying to d
On Saturday, 30 January, 2016 16:03, Simon Slavin
said:
> On 30 Jan 2016, at 8:13pm, Yannick Duch?ne
> wrote:
> > In my opinion (which some others share), OO is a bag of miscellaneous
> things which are better tools and better understood when accosted
> individually. Just trying to define what
On 31 Jan 2016, at 4:42pm, Keith Medcalf wrote:
> And I thought the "Object Oriented" jihad blew up when it was discovered to
> be counter to productivity and performance in the 1990's and that it did not
> provide a single one of the "advantages" claimed by its mujahedeen warriors.
Hmm. I t
On Sun, 31 Jan 2016 09:42:28 -0700
"Keith Medcalf" wrote:
>
> And I thought the "Object Oriented" jihad blew up when it was discovered to
> be counter to productivity and performance in the 1990's and that it did not
> provide a single one of the "advantages" claimed by its mujahedeen warriors
On Sat, 30 Jan 2016 20:50:17 -0500
Jim Callahan wrote:
> I am not interested in a complete ORM; what I am interested is when
> the object-oriented language supports a SQL-R-like object. In R, the
> object is called a data.frame and the package "Pandas" supplies a
> similar data frame object to Py
On Sat, 30 Jan 2016 23:03:29 +
Simon Slavin wrote:
> On 30 Jan 2016, at 8:13pm, Yannick Duch?ne
> wrote:
>
> > In my opinion (which some others share), OO is a bag of
> > miscellaneous things which are better tools and better understood
> > when accosted individually. Just trying to define
On Sun, Jan 31, 2016 at 6:25 PM, James K. Lowden
wrote:
> On Sat, 30 Jan 2016 20:50:17 -0500
> Jim Callahan wrote:
> But you already have pandas.read_sql_query. While that function
> isn't really what I'd call simple, the complexity afaict -- dates,
> floats, and chunks -- can be laid at Python'
On Sun, Jan 31, 2016 at 9:42 AM, Keith Medcalf wrote:
>
> And I thought the "Object Oriented" jihad blew up when it was discovered
> to be counter to productivity and performance in the 1990's and that it did
> not provide a single one of the "advantages" claimed by its mujahedeen
> warriors.
>
On 8 January 2016 at 01:47, Stephen Chrzanowski wrote:
> I personally wish the reverse. I wish that these interpreted language
> engines would incorporate the SQLite code directly into their own existence
> to avoid having to write wrappers to begin with, except for those wrappers
> where their
On 2016-11-06 3:50 AM, vfclists . wrote:
On 8 January 2016 at 01:47, Stephen Chrzanowski wrote:
I personally wish the reverse. I wish that these interpreted language
engines would incorporate the SQLite code directly into their own existence
to avoid having to write wrappers to begin with, exc
qlite-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users-
> boun...@mailinglists.sqlite.org] On Behalf Of Jim Callahan
> Sent: Thursday, January 07, 2016 7:23 PM
> To: SQLite mailing list
> Subject: [sqlite] Wish List for 2016: High Level API for Object Oriented
> Interactive La
37 matches
Mail list logo
