I've been working on a more or less complete rewrite of the
mysql-native module.
The main focus has been on making the source better decoupled and
more maintainable.
In the process, I've changed the API too...
The existing production code can be found here:
https://github.com/rejectedsoftwar
On Saturday, 28 September 2013 at 16:39:27 UTC, simendsjo wrote:
I've been working on a more or less complete rewrite of the
mysql-native module.
The main focus has been on making the source better decoupled
and more maintainable.
In the process, I've changed the API too...
The existing prod
On Saturday, 28 September 2013 at 16:39:27 UTC, simendsjo wrote:
I'm very uncertain about several aspects of my design:
* Class vs. struct
* Returned values from MySQL - e.g. should SELECT TRUE return
long as it does in MySQL, or should we interpret it as bool
* Probably a lot I don't remember
On Sunday, 29 September 2013 at 15:26:19 UTC, Gary Willoughby
wrote:
On Saturday, 28 September 2013 at 16:39:27 UTC, simendsjo wrote:
I'm very uncertain about several aspects of my design:
* Class vs. struct
* Returned values from MySQL - e.g. should SELECT TRUE return
long as it does in MySQL,
On Sunday, 29 September 2013 at 15:42:10 UTC, simendsjo wrote:
I don't think it's that simple in this case. When I implement
lazy fetching, both methods have it's advantages and
disadvantages.
MySQL doesn't allow multiplexing on a connection. This means a
command must complete before issuing an
On Sunday, 29 September 2013 at 15:42:10 UTC, simendsjo wrote:
the previous, but is this the best way? If we choose to
disallow new commands, that means the user have to explicitly
close a lazy command.
If a command isn't closed as soon as possible, it sounds like a
resource leak. If you sile
On Monday, 30 September 2013 at 10:34:25 UTC, Kagamin wrote:
On Sunday, 29 September 2013 at 15:42:10 UTC, simendsjo wrote:
the previous, but is this the best way? If we choose to
disallow new commands, that means the user have to explicitly
close a lazy command.
If a command isn't closed as
On Monday, 30 September 2013 at 11:20:23 UTC, simendsjo wrote:
Yeah. We need to choose:
1) Starting a new command while another is in flight is an error
You need to close explicitly if the command isn't finished
2) If another command has been started, it's er error to
continue iteration of a
On Monday, 30 September 2013 at 11:58:48 UTC, Kagamin wrote:
On Monday, 30 September 2013 at 11:20:23 UTC, simendsjo wrote:
Yeah. We need to choose:
1) Starting a new command while another is in flight is an
error
You need to close explicitly if the command isn't finished
2) If another comma
It's not only size. A popular use case is a log: you write lots
of entries and delete old ones, total size doesn't grow, but the
identifiers...
On Monday, 30 September 2013 at 12:05:49 UTC, simendsjo wrote:
I'll just add a hack for TINYINT(1) -> bool and keep everything
else MySQL specific.
Please don't. The db library should only return what mysql
returns. Let the next layer handle casting types.
Have to admit that int32 has been p
On Monday, 30 September 2013 at 11:58:48 UTC, Kagamin wrote:
int64 is the right type for a database integer, int32 is too
small. After all, it's a database.
All mysql types should be handled by using the correct type in D.
e.g. if i select an INT i want a D int. If i select a BINGINT i
want a
On 2013-09-30 13:20, simendsjo wrote:
Yeah. We need to choose:
1) Starting a new command while another is in flight is an error
You need to close explicitly if the command isn't finished
2) If another command has been started, it's er error to continue
iteration of a previous command.
I'm i
On 2013-09-30 15:07, Gary Willoughby wrote:
Please don't. The db library should only return what mysql returns. Let
the next layer handle casting types.
Agree.
--
/Jacob Carlborg
On Monday, 30 September 2013 at 14:00:10 UTC, Chris wrote:
It would be nice, if someone with experience wrote a short
article / tutorial about when to use structs and when to use
classes, where the pitfalls are etc.
I don't think there is a common consensus here. Don't even think
it is possib
On Saturday, 28 September 2013 at 16:39:27 UTC, simendsjo wrote:
I've been working on a more or less complete rewrite of the
mysql-native module.
The main focus has been on making the source better decoupled
and more maintainable.
In the process, I've changed the API too...
The existing prod
On Monday, 30 September 2013 at 14:08:12 UTC, Dicebot wrote:
On Monday, 30 September 2013 at 14:00:10 UTC, Chris wrote:
It would be nice, if someone with experience wrote a short
article / tutorial about when to use structs and when to use
classes, where the pitfalls are etc.
I don't think th
On Saturday, 28 September 2013 at 16:39:27 UTC, simendsjo wrote:
I've been working on a more or less complete rewrite of the
mysql-native module.
I don't have any specific comments. Just want to say that Steve
Teale originally wrote the module as part of his std.database
efforts. I think it
On 2013-09-30 16:08, Dicebot wrote:
I don't think there is a common consensus here. Don't even think it is
possible. Doom of proper multi-paradigm language :)
At least a few point can be made, like:
* For reference types use classes, or use structs with reference counting
* For sub typing use
On Monday, 30 September 2013 at 13:33:09 UTC, Jacob Carlborg
wrote:
On 2013-09-30 15:07, Gary Willoughby wrote:
Please don't. The db library should only return what mysql
returns. Let
the next layer handle casting types.
Agree.
Seems everyone agrees on this. In that case, I won't do any ki
On Monday, 30 September 2013 at 16:27:16 UTC, Brad Anderson wrote:
On Saturday, 28 September 2013 at 16:39:27 UTC, simendsjo wrote:
I've been working on a more or less complete rewrite of the
mysql-native module.
I don't have any specific comments. Just want to say that
Steve Teale originall
On Monday, 30 September 2013 at 17:19:44 UTC, Jacob Carlborg
wrote:
On 2013-09-30 16:08, Dicebot wrote:
I don't think there is a common consensus here. Don't even
think it is
possible. Doom of proper multi-paradigm language :)
At least a few point can be made, like:
* For reference types us
On 2013-09-30 20:14, simendsjo wrote:
I don't agree that this library should aim for any inclusion in phobos.
I plan on exposing the MySQL API as closely as possible and a couple of
higher level convenience functions. The std.database would have to be
database agnostic, and should be a library i
On Monday, 30 September 2013 at 18:14:13 UTC, simendsjo wrote:
On Monday, 30 September 2013 at 16:27:16 UTC, Brad Anderson
wrote:
On Saturday, 28 September 2013 at 16:39:27 UTC, simendsjo
wrote:
I've been working on a more or less complete rewrite of the
mysql-native module.
I don't have any
On Tuesday, 1 October 2013 at 08:05:29 UTC, ilya-stromberg wrote:
On Monday, 30 September 2013 at 18:14:13 UTC, simendsjo wrote:
On Monday, 30 September 2013 at 16:27:16 UTC, Brad Anderson
wrote:
On Saturday, 28 September 2013 at 16:39:27 UTC, simendsjo
wrote:
I've been working on a more or les
On Mon, 30 Sep 2013 20:14:12 +0200
"simendsjo" wrote:
> On Monday, 30 September 2013 at 16:27:16 UTC, Brad Anderson wrote:
> > On Saturday, 28 September 2013 at 16:39:27 UTC, simendsjo wrote:
> >> I've been working on a more or less complete rewrite of the
> >> mysql-native module.
> >
> > I don
On Sat, 28 Sep 2013 18:38:47 +0200, simendsjo wrote:
> I've been working on a more or less complete rewrite of the
> mysql-native module.
>
I think this is a great first step. Code is more readable, easier
to follow (compared to the pointer stuff in the original).
Code has some distinctly 64bi
On Tuesday, 8 October 2013 at 17:47:02 UTC, ollie wrote:
On Sat, 28 Sep 2013 18:38:47 +0200, simendsjo wrote:
I've been working on a more or less complete rewrite of the
mysql-native module.
I think this is a great first step. Code is more readable,
easier
to follow (compared to the point
28 matches
Mail list logo
