Hello everyone,
I am new to the list. I am working on an application in which I will be
embedding SQLite as the database engine. The application is written in
C.
I am currently having an issue which I am not able to resolve at the
moment so I thought I would ask here since I am just starting out
On 5 Jun 2015, at 9:14pm, Joe Mucchiello wrote:
> All these subject lines about UDTs in SQLite and the one and only thing I
> would use such a thing for is not listed: Date/Time values. I'd love for
> there to be native date/time formats in SQLite. I'm surprised it never came
> up. Although I
All these subject lines about UDTs in SQLite and the one and only thing I would
use such a thing for is not listed: Date/Time values. I'd love for there to be
native date/time formats in SQLite. I'm surprised it never came up. Although
I'm also surprised the NoSQL-ite came up.
> That's six sets
On Fri, Jun 05, 2015 at 09:36:09PM +0100, Simon Slavin wrote:
> One advantage I can think of of having a DateTime type -- enforcement
> of storing the correct thing in the correct column -- won't work in
> SQLite anyway, because rather than enforce column types is uses only
> affinities.
>
> How w
On Thu, 4 Jun 2015 15:11:55 -0700
Darko Volaric wrote:
> Are you seriously saying that that SQL syntax is friendly? How can you
> defend SQL syntax other than on grounds of history or
> standardization?
The first and best defense of SQL is that it has at least some
basis in the relational model.
On Fri, 5 Jun 2015 13:07:59 -0400
Stephen Chrzanowski wrote:
> If N-Tier software development is 'annoying' and you are not happy,
> either get help by other members of your team, or, find a different
> hobby, because anything less than 3-tier programming dealing with
> multiple languages, techno
On 5 Jun 2015, at 3:05pm, Don V Nielsen wrote:
> I do all kinds of --stuff--
> using Ruby and PHP. And the --stuff-- gets translated to SQL and sent to
> my favorite db, Sqlite.
I find it very annoying that in order to do good Web-facing systems I have to
know all the following:
HTML (and CS
Yes, the relational model is the key, that is my point. The SQL language is
an entirely arbitrary syntax applied to it. You don't need it to work a
relational database, just like you don't have to program in C to write a
program for a typical processor.
I don't care about how many applications hav
On Fri, Jun 5, 2015 at 11:07 AM, Stephen Chrzanowski
wrote:
> First, who said that you had to keep all 6 sets of languages in your head
> at once? I've never been told that, and I've been doing software
> development since I was 8, taken several training courses in elementary,
> high school, col
First, who said that you had to keep all 6 sets of languages in your head
at once? I've never been told that, and I've been doing software
development since I was 8, taken several training courses in elementary,
high school, college, and while employed by three different companies (At
different ti
> How can you defend SQL syntax other than on grounds of history or
standardization?
Short answer: QWERTY.
Long answer: IBM mainframe DOS -> Z/OS. A 1960's o/s that is still
supported by the inner workings of its most modern o/s.
There's is nothing wrong with supporting the past. Sometimes
What you're looking for seems similar to LINQ to SQLite (System.Data.SQLite).
When programming in C#, I don't code any SQL. I use a strongly-typed interface
that then generates SQL queries in the background.
Besides LINQ, you could create another interface that suits your needs, and
that can th
There's a bit of confusion as to what I'm actually proposing. I can't reply
to everyone so I'll just post the APIs and/or patches when they're done and
we can argue those on their merits.
On Thu, Jun 4, 2015 at 5:03 PM, Darko Volaric wrote:
> Well, I've been using SQL for about 30 years so I'm u
On 2015-06-05 12:11 AM, Darko Volaric wrote:
> Are you seriously saying that that SQL syntax is friendly? How can you
> defend SQL syntax other than on grounds of history or standardization? If
> you're more comfortable and familiar with JSON the yes it is easier and you
> can avoid an unnecessar
On 5 Jun 2015, at 12:11am, Richard Hipp wrote:
> I just want to ensure that if, after working on your new approach for
> a while, you eventually decide that SQL isn't quite as bad a language
> as you originally thought it was, that you don't come back and say I
> didn't warn you.
I'm on my thir
On 2015-06-04 11:16 PM, Darko Volaric wrote:
> My point about JSON, etc is that there is no reason not to use that as a
> query language if that makes it easier. If your system is efficient with
> JSON, why not accept a query that is formatted as JSON? It's not
> semantically different to SQL syn
16 matches
Mail list logo
