s-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 <sqlite-users@mailinglists.sqlite.org>
> Subject: [sqlite] Wish List for 2016: High Level API for Objec
eeded to. My problem is that
gaming gets in the way.
My 2016 wish list for SQLite is that all developers who write for, or use
directly or indirectly, any database engine out on the market has a safe
and happy 2016 and beyond.
Haven't the mORMot guys already done this -
http://synopse.info/fossil/
lways read up on other specifications if I needed to. My problem is that
> gaming gets in the way.
>
> My 2016 wish list for SQLite is that all developers who write for, or use
> directly or indirectly, any database engine out on the market has a safe
> and happy 2016 an
> 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:
>
> > 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
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
> > 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
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 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
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
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 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
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
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
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
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
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,
>
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
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
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
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
-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
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
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
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
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
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
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
ew years, I've considered taking the entire amalgamation and
>> porting
>> it to Pascal (Delphi/FPC) so I have exactly zero reliance on DLLs. No
>> worries about OBJ files, no worries about dependencies, I just include a
>> unit and my app is now database aware. I kno
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
amation and porting
> it to Pascal (Delphi/FPC) so I have exactly zero reliance on DLLs. No
> worries about OBJ files, no worries about dependencies, I just include a
> unit and my app is now database aware. I know 386 assembly, and I can
> always read up on other specifications if
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
ut OBJ files, no worries about dependencies, I just include a
unit and my app is now database aware. I know 386 assembly, and I can
always read up on other specifications if I needed to. My problem is that
gaming gets in the way.
My 2016 wish list for SQLite is that all developers who write for, or u
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 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 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
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
On 24 Dec 2015 at 15:26, Bernardo Sulzbach
wrote:
> want a more versatile alter table for convenience. However, I don't
> know if alter table is used at all in production anywhere (why would
> it be? the column names and ordering should not be part of the data).
If I distribute an app with a
On Thu, Dec 24, 2015 at 2:30 PM, Tim Streater wrote:
> On 24 Dec 2015 at 15:26, Bernardo Sulzbach
> wrote:
>
>> want a more versatile alter table for convenience. However, I don't
>> know if alter table is used at all in production anywhere (why would
>> it be? the column names and ordering
39 matches
Mail list logo
