On 4 Jun 2015, at 10:16pm, Darko Volaric wrote:
> Here's an example (with a roughly
> JSON notation):
>
> {
> operation: "insert"
> table: "blah"
> columns: ["a", "b", "c"]
> values: [1.3, 2.0, 3.1]
> on-conflict: "replace"
> }
>
> That is equivalent to an INSERT SQL statement, but why
On 6/4/15, Darko Volaric wrote:
>
> What is motivating this for me is that I generate many unique queries in my
> code for almost any operation. Converting those to SQL is error prone and
> uses a lot of memory compared to the operation involved. The database
> engine is so fast and efficient yet
On 2015-06-05 12:11 AM, Darko Volaric wrote:
>I now regret using JSON as an example since everyone wants me to
>convert SQL to JSON for them now, but my point isn't any particular
>notation, I want an API of sorts instead of a notation or syntax. Then
>you can adapt anything you like and make
If you really want your own types, you could always bundle with ASN.1 and
store the result as a blob.
On Thu, Jun 4, 2015 at 4:52 PM, Dominique Devienne
wrote:
> On Thu, Jun 4, 2015 at 3:04 AM, Darko Volaric wrote:
>
> > In my case I'm already modifying and maintaining my own version of
>
On Thu, Jun 04, 2015 at 03:36:34PM -0700, Darko Volaric wrote:
> I now regret using JSON as an example since everyone wants me to convert
> [...]
So you don't like the SQL language, but if you're after UDTs and your
first stop is to design a different language (or merely make it easier
for you to
On Thu, Jun 4, 2015 at 4:21 PM, Darko Volaric wrote:
> I'm saying that SQL is alien to the platform it's being used on and native
> is better. I'm trying to make a general point (in vain it seems), I don't
> use JSON.
>
{bunch of stuff snipped}
I understand where you're coming from, I think. I
On 6/4/15, 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 syntax. Here's
Well, I've been using SQL for about 30 years so I'm unlikely to change my
view, but I think you bring up a much more important point: instead of
arguing online I should get back to work!
On Thu, Jun 4, 2015 at 4:11 PM, Richard Hipp wrote:
> On 6/4/15, Darko Volaric wrote:
> >
> > What is
Just write your program in C. Use the C syntax to do whatever
you want and you have full control over the minutiae.
Scott Doctor
scott at scottdoctor.com
--
> On 6/4/15, Darko Volaric wrote:
>> What is motivating this for me is that I generate many unique
On Thu, Jun 04, 2015 at 02:16:22PM -0700, Darko Volaric wrote:
> {
> operation: "insert"
> table: "blah"
> columns: ["a", "b", "c"]
> values: [1.3, 2.0, 3.1]
> on-conflict: "replace"
> }
I do this all the time. It's trivial enough to generate SQL from that
sort of thing. If you have
I now regret using JSON as an example since everyone wants me to convert
SQL to JSON for them now, but my point isn't any particular notation, I
want an API of sorts instead of a notation or syntax. Then you can adapt
anything you like and make it efficient with the platform you're using. So
for
I'm saying that SQL is alien to the platform it's being used on and native
is better. I'm trying to make a general point (in vain it seems), I don't
use JSON.
On Thu, Jun 4, 2015 at 2:46 PM, Simon Slavin wrote:
>
> On 4 Jun 2015, at 10:16pm, Darko Volaric wrote:
>
> > Here's an example (with a
Yes, you can do that but I'm trying to remove steps and conversions, not
add more. My point is that a more native interface is better than SQL.
Yes it's basic, but as I said, a first step. I'm making changes to one
part, making changes to another part makes no difference. The fork has been
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 unnecessary conversion step.
If you're using JavaScript you'd
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 syntax. Here's an example (with a roughly
JSON notation):
On Thu, Jun 04, 2015 at 11:45:28AM -0700, Darko Volaric wrote:
> Which sort of leads me to my next feature, which is bypassing the SQL
> language. [...]
I like SQL, but sure, if the compiler worked by first parsing into an
AST, and if the AST were enough of an interface (versioned, though not
On Thu, Jun 04, 2015 at 10:54:16AM +0200, Dominique Devienne wrote:
> On Thu, Jun 4, 2015 at 10:20 AM, Christopher Vance
> wrote:
> > If you really want your own types, you could always bundle with ASN.1 and
> > store the result as a blob.
FYI, Heimdal has a very nice, small, simple, featureful,
On Wed, Jun 03, 2015 at 06:04:29PM -0700, Darko Volaric wrote:
> Yep, references a another one. Just like the functions, you have to join on
> the user type information, add it to constraints, etc.
Once you're extending SQLite3 proper the referential integrity problem
goes away (being no
On Thu, Jun 4, 2015 at 1:54 AM, Dominique Devienne
wrote:
> On Thu, Jun 4, 2015 at 10:20 AM, Christopher Vance
> wrote:
>> If you really want your own types, you could always bundle with ASN.1 and
>> store the result as a blob.
>
> Or Protobuf, or ... But you're back to option 1, you must
Hello
Exception when using SQLite, Entity FW and programmatically configuring
DBConfiguration.
(BTW it works perfectly fine if settings are done in app.config instead of
programmatic. But as a library developer I do not want to ask clients to put
some config settings in their app.config. I
Which sort of leads me to my next feature, which is bypassing the SQL
language. Why use that crusty old syntax when it's equally expressible in
JSON, XML or something else. Again I see it just as an API, callable by
whatever parser you want, or none at all, if your code generates queries
directly.
On Thu, Jun 4, 2015 at 10:20 AM, Christopher Vance
wrote:
> If you really want your own types, you could always bundle with ASN.1 and
> store the result as a blob.
>
Or Protobuf, or ... But you're back to option 1, you must store somewhere
that knowledge, and it's an app-convention, SQL and
On 6/3/15, Brian Green wrote:
> one of the queries my application uses joins
> two subqueries together, and the use of an automatic index can create a
> dramatic difference in the query performance. SQLite does choose to create
> an automatic index if I run 'analyze', however running 'analyze'
On Thu, Jun 4, 2015 at 3:04 AM, Darko Volaric wrote:
> In my case I'm already modifying and maintaining my own version of SQLite.
> [...]. The last time I brought these ideas up I was
> practically chased off by a mob waving pitchforks and torches. Apparently
> almost no-one thinks user defined
That's an entirely valid point, but didn't come up in the discussions if
memory serves. It was the "you don't know what you're doing and don't
understand databases" which I thought was an odd response, but that's all
irrelevant.
I agree that feature bloat is not a good idea (hello, PgSQL!) and I
On 2015-06-03 20:52, Simon Slavin wrote:
> On 3 Jun 2015, at 8:54pm, Justin Clift wrote:
>
>> It looks like the SourceForge admin staff have taken control
>> of the "sqlite" project on SourceForge:
>>
>> http://sourceforge.net/mirror/sqlite/
>
> Don't worry about it. As the page says, the
26 matches
Mail list logo
