On Sunday, 1 January 2017 at 03:24:31 UTC, Adam Wilson wrote:
Hi Everyone,
I've seen a lot of talk on the forums over the past year about
the need for database support in the D Standard Library and I
completely agree. At the end of the day the purpose of any
programming language and its atten
On 2017-01-03 18:13, Chris Wright wrote:
The returned row data is mandatory, and its size can be much larger than
the stack limit. (A MySQL MEDIUMBLOB field will likely break your stack
limit.)
I suppose you could have a streaming API for row data, one that has a
stack-allocated buffer and retu
On Tue, 03 Jan 2017 13:23:55 +0100, Jacob Carlborg wrote:
> On 2017-01-03 09:38, Chris Wright wrote:
>
>> You are unable to interact with two different databases in the same
>> executable using the same library. For instance, if you're using
>> hibernated, either you compiled it to connect to mys
On 2017-01-03 09:38, Chris Wright wrote:
You are unable to interact with two different databases in the same
executable using the same library. For instance, if you're using
hibernated, either you compiled it to connect to mysql, or you compiled
it to connect to oracle.
That's true. And that's
On Tuesday, 3 January 2017 at 08:09:54 UTC, Chris Wright wrote:
On Mon, 02 Jan 2017 21:25:42 -0800, Adam Wilson wrote:
As far as I am aware, the only way to meet those requirements
is to use a base-class model. Is there something I am missing?
Templates. Templates everywhere.
Every method in
On Tue, 03 Jan 2017 08:25:55 +0100, Jacob Carlborg wrote:
> Structs and functions, with or without templates. Could something like
> this work:
>
> module db_interface;
>
> version (Postgres)
> public import pg.db_interface;
> else version (MySQL)
> public import mysql.db_interface;
Y
On Mon, 02 Jan 2017 21:25:42 -0800, Adam Wilson wrote:
> As far as I am aware, the only way to meet those requirements is to use
> a base-class model. Is there something I am missing?
Templates. Templates everywhere.
Every method in your application that might possibly touch a database, or
touch
On 2017-01-03 06:25, Adam Wilson wrote:
Ok. How would you design a database API for D?
I don't know. I think it's difficult to design something upfront without
trying out different API's to see what's possible to implement in code.
Structs and functions, with or without templates. Could som
On 1/2/17 12:09 AM, Jacob Carlborg wrote:
On 2017-01-02 02:34, Adam Wilson wrote:
That was my intention, the knee-jerk reaction that class and interfaces
get here sometimes strikes me as a bit histrionic sometimes. They are a
tool with a use case. :)
I think that the design should try to avoi
On 1/2/17 12:05 AM, Jacob Carlborg wrote:
On 2017-01-01 17:50, Chris Wright wrote:
Those both limit your ability to use the underlying database to its full
potential. They offer a chance for queries that seem simple and efficient
to become horribly inefficient.
I'm perfectly aware of the limi
On 1/2/17 8:33 AM, Chris Wright wrote:
On Sun, 01 Jan 2017 17:55:01 -0800, Adam Wilson wrote:
On that I beg to differ. The C libraries are not @safe, they have wildly
different API's, and they have high-complexity, which is a large
risk-factor for bugs and/or security flaws.
If we have the dat
On Sun, 01 Jan 2017 17:55:01 -0800, Adam Wilson wrote:
> On that I beg to differ. The C libraries are not @safe, they have wildly
> different API's, and they have high-complexity, which is a large
> risk-factor for bugs and/or security flaws.
If we have the database interface defined, there's no r
On 2017-01-01 17:50, Chris Wright wrote:
Those both limit your ability to use the underlying database to its full
potential. They offer a chance for queries that seem simple and efficient
to become horribly inefficient.
I'm perfectly aware of the limitations and capabilities of ORM's. I'm
jus
On 2017-01-02 02:34, Adam Wilson wrote:
That was my intention, the knee-jerk reaction that class and interfaces
get here sometimes strikes me as a bit histrionic sometimes. They are a
tool with a use case. :)
I think that the design should try to avoid classes as much as possible
for things t
On 02/01/2017 4:44 PM, Adam Wilson wrote:
rikki cattermole wrote:
On 02/01/2017 3:03 PM, Adam Wilson wrote:
rikki cattermole wrote:
On 01/01/2017 5:19 PM, Adam D. Ruppe wrote:
On Sunday, 1 January 2017 at 03:51:52 UTC, rikki cattermole wrote:
Which is fine if all you use is c's sockets or on
rikki cattermole wrote:
On 02/01/2017 3:03 PM, Adam Wilson wrote:
rikki cattermole wrote:
On 01/01/2017 5:19 PM, Adam D. Ruppe wrote:
On Sunday, 1 January 2017 at 03:51:52 UTC, rikki cattermole wrote:
Which is fine if all you use is c's sockets or only that database
connection for a thread.
On 02/01/2017 3:03 PM, Adam Wilson wrote:
rikki cattermole wrote:
On 01/01/2017 5:19 PM, Adam D. Ruppe wrote:
On Sunday, 1 January 2017 at 03:51:52 UTC, rikki cattermole wrote:
Which is fine if all you use is c's sockets or only that database
connection for a thread.
The C drivers typically
rikki cattermole wrote:
On 01/01/2017 5:19 PM, Adam D. Ruppe wrote:
On Sunday, 1 January 2017 at 03:51:52 UTC, rikki cattermole wrote:
Which is fine if all you use is c's sockets or only that database
connection for a thread.
The C drivers typically offer handles of some sort (Windows HANDLE,
Adam D. Ruppe wrote:
On Sunday, 1 January 2017 at 03:24:31 UTC, Adam Wilson wrote:
interface(s) to a data-store an essential component of the D Standard
Library.
Eh, I count it as would-be-nice just because it isn't that hard to just
use the C ones, or another third party lib; it doesn't have
Chris Wright wrote:
On Sat, 31 Dec 2016 19:24:31 -0800, Adam Wilson wrote:
My idea: Split the data storage systems out by category of data-store.
For example:
- SQL: std.database.sql (PostgreSQL, MySQL, MSSQL, etc.)
This is doable; SQL is an ANSI and ISO standard, and it strongly
const
Chris Wright wrote:
On Sun, 01 Jan 2017 10:29:28 +0100, Jacob Carlborg wrote:
On 2017-01-01 04:24, Adam Wilson wrote:
My idea: Each data store has it's own implementation with it's own
naming convention. For example (ADO.NET):
- SqlConnection (MSSQL)
- NpgsqlConnection (Npgsql)
Y
Chris Wright wrote:
On Sat, 31 Dec 2016 19:24:31 -0800, Adam Wilson wrote:
My idea: Each data store has it's own implementation with it's own
naming convention. For example (ADO.NET):
- SqlConnection (MSSQL)
- NpgsqlConnection (Npgsql)
Yes, this means that you have to change nam
Mark wrote:
On Sunday, 1 January 2017 at 03:24:31 UTC, Adam Wilson wrote:
2. There are so many different types of data storage systems, how do
you design a system generic enough for all of them?
My answer: You don't. Nobody else has bothered trying, and I believe
that our worry over that questi
On Sunday, 1 January 2017 at 03:24:31 UTC, Adam Wilson wrote:
2. There are so many different types of data storage systems,
how do you design a system generic enough for all of them?
My answer: You don't. Nobody else has bothered trying, and I
believe that our worry over that question is a lar
On Sat, 31 Dec 2016 19:24:31 -0800, Adam Wilson wrote:
> My idea: Each data store has it's own implementation with it's own
> naming convention. For example (ADO.NET):
> - SqlConnection (MSSQL)
> - NpgsqlConnection (Npgsql)
>
> Yes, this means that you have to change names in your code
On Sun, 01 Jan 2017 10:29:28 +0100, Jacob Carlborg wrote:
> On 2017-01-01 04:24, Adam Wilson wrote:
>
>> My idea: Each data store has it's own implementation with it's own
>> naming convention. For example (ADO.NET):
>> - SqlConnection (MSSQL)
>> - NpgsqlConnection (Npgsql)
>>
>> Yes, t
On 2017-01-01 04:24, Adam Wilson wrote:
My idea: Each data store has it's own implementation with it's own
naming convention. For example (ADO.NET):
- SqlConnection (MSSQL)
- NpgsqlConnection (Npgsql)
Yes, this means that you have to change names in your code if you switch
data-stores
On Sat, 31 Dec 2016 19:24:31 -0800, Adam Wilson wrote:
> My idea: Split the data storage systems out by category of data-store.
> For example:
> - SQL: std.database.sql (PostgreSQL, MySQL, MSSQL, etc.)
This is doable; SQL is an ANSI and ISO standard, and it strongly
constrains what you can
On 01/01/2017 5:19 PM, Adam D. Ruppe wrote:
On Sunday, 1 January 2017 at 03:51:52 UTC, rikki cattermole wrote:
Which is fine if all you use is c's sockets or only that database
connection for a thread.
The C drivers typically offer handles of some sort (Windows HANDLE, *nix
file descriptor, th
On Sunday, 1 January 2017 at 03:24:31 UTC, Adam Wilson wrote:
interface(s) to a data-store an essential component of the D
Standard Library.
Eh, I count it as would-be-nice just because it isn't that hard
to just use the C ones, or another third party lib; it doesn't
have to be Phobos itself.
On Sunday, 1 January 2017 at 03:51:52 UTC, rikki cattermole wrote:
Which is fine if all you use is c's sockets or only that
database connection for a thread.
The C drivers typically offer handles of some sort (Windows
HANDLE, *nix file descriptor, that kind of thing) that you can
integrate in
On 01/01/2017 4:46 PM, Adam Wilson wrote:
On 12/31/16 7:31 PM, rikki cattermole wrote:
We do indeed need a good database abstraction.
But a core requirement for any implementation has yet to be met.
There has to be a standard way for asynchronous sockets. To implement
this we need to take into
On 12/31/16 7:31 PM, rikki cattermole wrote:
We do indeed need a good database abstraction.
But a core requirement for any implementation has yet to be met.
There has to be a standard way for asynchronous sockets. To implement
this we need to take into consideration the event loop that it uses a
We do indeed need a good database abstraction.
But a core requirement for any implementation has yet to be met.
There has to be a standard way for asynchronous sockets. To implement
this we need to take into consideration the event loop that it uses and
more importantly allow it to be integrate
Hi Everyone,
I've seen a lot of talk on the forums over the past year about the need
for database support in the D Standard Library and I completely agree.
At the end of the day the purpose of any programming language and its
attendant libraries is to allow the developer to solve their problem
35 matches
Mail list logo
