On 2015-01-11 02:08, DaveG wrote:
In the past I have used FreeTDS, through PHP, and it had a lot of
problems. This was several years ago and could have been at least
partially due to the PHP layer.
Last year I messed around with the ODBC wrapper and got amazingly poor
performance, I believe
On 2015-01-10 21:53, DaveG wrote:
One final note. You may have noticed I didn't mention the schema syncing
problem (keeping database and code in sync). There was a time I would
have said that was essential and while it would be nice in a perfect
world, I'm comfortable keeping them in sync
On Saturday, 10 January 2015 at 20:53:47 UTC, DaveG wrote:
On Saturday, 10 January 2015 at 18:31:18 UTC, Paolo Invernizzi
wrote:
I would like to see, someday, something in D that:
- can check at compile time the syntax of SQL;
- can check at compile time the SQL query statement against
the
On Sunday, 11 January 2015 at 09:54:42 UTC, Jacob Carlborg wrote:
On 2015-01-11 02:08, DaveG wrote:
In the past I have used FreeTDS, through PHP, and it had a lot
of
problems. This was several years ago and could have been at
least
partially due to the PHP layer.
Last year I messed around
On Sunday, 11 January 2015 at 10:06:53 UTC, Paolo Invernizzi
wrote:
On Saturday, 10 January 2015 at 20:53:47 UTC, DaveG wrote:
On Saturday, 10 January 2015 at 18:31:18 UTC, Paolo Invernizzi
wrote:
I would like to see, someday, something in D that:
- can check at compile time the syntax of
On 1/11/15 8:21 AM, DaveG wrote:
On Sunday, 11 January 2015 at 09:54:42 UTC, Jacob Carlborg wrote:
On 2015-01-11 02:08, DaveG wrote:
In the past I have used FreeTDS, through PHP, and it had a lot of
problems. This was several years ago and could have been at least
partially due to the PHP
On 01/10/2015 01:36 PM, Martin Nowak wrote:
The idea isn't bad, but the performance will suck. This is generally
known as N+1 query, only that this is even worse, as each field is
queried individually.
Here is a sketch for an optimal solution. I'm actually eagerly waiting
that someone finally
On 2015-01-10 07:46, DaveG wrote:
Let me preface this by saying I only have a general conceptual
understanding of compilers and know nothing about actual implementation.
One common problem with Object-Relational Mapping (ORM) is what data to
load and when. There is basically 2 options:
1. Load
On 2015-01-10 14:19, Martin Nowak wrote:
I'd simple produce multiple rows, the principle remains the same.
Ok, I think I understand the code now. You managed to register the
fields at compile time. Pretty neat. I thought the query would need to
be delayed to the first call to opDispatch.
On 2015-01-10 13:36, Martin Nowak wrote:
The idea isn't bad, but the performance will suck. This is generally
known as N+1 query, only that this is even worse, as each field is
queried individually.
Since the all method was called I would assume all rows in the person
table are fetched in
On 01/10/2015 11:20 AM, Jacob Carlborg wrote:
On 2015-01-10 07:46, DaveG wrote:
I might be crazy, but it seems like the compiler has all the information
necessary to figure this out and it would make user code simpler, less
error prone, and more efficient. So does anybody have any idea on how
On 01/10/2015 01:52 PM, Jacob Carlborg wrote:
On 2015-01-10 13:36, Martin Nowak wrote:
The idea isn't bad, but the performance will suck. This is generally
known as N+1 query, only that this is even worse, as each field is
queried individually.
Since the all method was called I would assume
On 2015-01-10 13:36, Martin Nowak wrote:
I'm actually eagerly waiting that someone finally implements it.
There are two ORM libraries at code.dlang.org [1] [2]. Although I don't
know how usable they are.
[1] http://code.dlang.org/packages/hibernated
[2]
On Saturday, 10 January 2015 at 13:19:19 UTC, Martin Nowak wrote:
On 01/10/2015 01:52 PM, Jacob Carlborg wrote:
On 2015-01-10 13:36, Martin Nowak wrote:
The idea isn't bad, but the performance will suck. This is
generally
known as N+1 query, only that this is even worse, as each
field is
On Saturday, 10 January 2015 at 20:51:44 UTC, Jacob Carlborg
wrote:
That would be FreeTDS [1] with D bindings [2]. Unless Microsoft
have headers available for interfacing with SQL Server.
You can use ODBC if it is a Windows program. If you want to talk
to SQL Server from a Linux program
On Saturday, 10 January 2015 at 18:31:18 UTC, Paolo Invernizzi
wrote:
On Saturday, 10 January 2015 at 17:31:42 UTC, DaveG wrote:
On Saturday, 10 January 2015 at 13:19:19 UTC, Martin Nowak
wrote:
Here is a sketch for an optimal solution. I'm actually
eagerly waiting that someone finally
On 2015-01-10 18:31, DaveG wrote:
Oh, we will also need a good SQL Server library which, to my knowledge,
D is lacking. This is going to be a hard sell...
That would be FreeTDS [1] with D bindings [2]. Unless Microsoft have
headers available for interfacing with SQL Server.
[1]
On Saturday, 10 January 2015 at 17:31:42 UTC, DaveG wrote:
On Saturday, 10 January 2015 at 13:19:19 UTC, Martin Nowak
wrote:
Here is a sketch for an optimal solution. I'm actually eagerly
waiting that someone finally implements it.
http://dpaste.dzfl.pl/cd375ac594cf
I would also have to
On Saturday, 10 January 2015 at 20:57:00 UTC, Adam D. Ruppe wrote:
On Saturday, 10 January 2015 at 20:51:44 UTC, Jacob Carlborg
wrote:
That would be FreeTDS [1] with D bindings [2]. Unless
Microsoft have headers available for interfacing with SQL
Server.
You can use ODBC if it is a Windows
Let me preface this by saying I only have a general conceptual
understanding of compilers and know nothing about actual
implementation.
One common problem with Object-Relational Mapping (ORM) is what
data to load and when. There is basically 2 options:
1. Load everything: This certainly
20 matches
Mail list logo
