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.
