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 plenty for me in the past. Never worked on databases with > 200M rows.

I routinely use db's with enormous datasets 500M+ and use BIGINTS a lot. If i select a BIGINT column i'd expect a long back.

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 D long, etc.

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 in favor of 1).

I would go with one as well.

> Yeah. BOOL is an alias for TINYINT(1). I think it's fair to always
> assume TINYINT(1) is bool. For other types I'm not quite sure though..
> "SELECT 1" is a LONGLONG, but in D a literal is int unless specified
> otherwise. So there is a mismatch here.

Use the type in D which has the closets match and have the same length. Type conversions can be made later in a higher level API.

-- 
/Jacob Carlborg

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 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 production code can be found here: https://github.com/rejectedsoftware/mysql-native
>
> New code: http://simendsjo.me/files/simendsjo/mysqln-rewrite/mysqln-rewrite.7z
> Documentation: http://simendsjo.me/files/simendsjo/mysqln-rewrite/docs/
>
> The files:
> * adhoc.d - Execute simple queries. This is meant to be the new high-level public API
> * commands.d - Lower level public API
> * result.d - Common interface for both Text and Binary MySQL results
> * connection.d - Phobos/Vibe.d connection
> * db.d - Vibe.d connection pool
>
> The rest are just internal files.
>
> Todo:
> * Implement all MySQL types
> * Prepared statement release/purge
> * Lazily fetch data
> * Fix bugs in prepared statement binding
> * Implement SEND_LONG_DATA
> * More integrationtests and unittests
>
> Most of the above would be pretty simple to implement.
>
> 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 right now :)
>
> Any comments would be very helpful.
> ..Or in D terms: DESTROY!

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. It is not always easy to decide and a rough guide would be great. As of now I'm using structs and ranges only for reformatting input. I'm not sure, however, if it is a good idea to go beyond this (cf. different reference semantics, polymorphism etc.)

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 possible. Doom of proper multi-paradigm language :)

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 there is a common consensus here. Don't even think it is possible. Doom of proper multi-paradigm language :)

Well, if people shared their experience with ranges / structs vs. classes, it would be a good reference point for other programmers. There might not be any real rules, but rough guidelines would help, e.g. "If you want to achieve X, structs are better, because blah blah. But if you want to do Y, there might be a problem with structs. Better use classes." Maybe structs are better suited for parallel processing and multi threading (value vs reference), or maybe not? Just a collection of little hints would make life simpler. I'm sure someone has shot him/herself seriously in the foot using either structs or classes.

I use structs mainly for a. formatting and reformatting (I/O) and b. data storage. Classes I use for the overall logic of the program (with the usual suspects like controller, model, proxies ...) But I'm always willing to learn new tricks (this dog is not too old yet!).

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 would be nice if any redesign done would aim for eventual phobos inclusion.

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 classes, or use structs with alias this
* For polymorphic types use classes
* For value types use structs
* For deterministic destruction use structs

-- 
/Jacob Carlborg

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 kind of processing of the types.