[RFC] - mysql-native rewrite

[simendsjo]

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, 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!
>
> Ok, i've taken a quick look and like where this is going. I'll 
> try and give you a little guide to what i would do regarding 
> the above points.
>
>> * Class vs. struct
>
> I tend to only use structs where the type is purely a data 
> type. Something like a record or a type that can be manifested 
> in different ways (such as an IP address). If i need to model a 
> real world object like an engine or book, etc., i use a class.

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 another. If reading rows 
lazily and then issuing a new command, the choice is to either 
disallow the new command, or invalidate the previous. The simple 
way would be to just start a new command and invalidate 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 using classes, we can safely have several instances 
for a command (is this neccessary?), but then the destructor 
wont't be a safe bet, and the user have to call close.
If implemented as a struct, we have to disallow copying.

So... I really don't know what the best design would be.

>> * Returned values from MySQL - e.g. should SELECT TRUE return 
>> long as it does in MySQL, or should we interpret it as bool
>
> I would return what mysql yields. This would make sure this 
> framework is not doing to much. Converting ints to bools would 
> be the next layer's job (DBAL, ORM, etc.).

The problem is that MySQL is inconsistent here, and it depends on 
if it's a field or a constant. SELECT TRUE is not the same as 
SELECT boolean_field.
Also, it seems every constant integer is returned as LONGLONG. 
But.. The fields include a length property..

> I have two more suggestions that i think is critical to a 
> project such as this and that's documentation and unit tests.
>
> Please from the start thoroughly annotate everything with ddoc 
> to generate nice html docs later. I know this can be a pain 
> when designing and developing an API but is absolutely 
> necessary. If you leave documentation until the end it never 
> gets done!

Yeah, the documentation isn't very good :/

Thought I'd get feedback on the API before spending a lot of time 
documenting it.

> Write unit tests for everything. I've found that if you find it 
> hard to write a unit test for any 'unit', etc then it's too 
> tightly coupled and probably doing too much. Practise good 
> SOLID design principles and unit tests should be easy to write. 
> Not only that but unit tests provide developers with a good 
> understanding of the public interface.
>
> http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

Most of the code is easy to unittest, but for now I've just 
relied on integration tests against a database. I'll improve on 
the situation.