<br><br><div class="gmail_quote">On 10 October 2012 05:35, Reinier Olislagers <span dir="ltr"><<a href="mailto:reinierolislagers@gmail.com" target="_blank">reinierolislagers@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 6-10-2012 14:34, Michael Van Canneyt wrote:<br>
</div><div class="im">> On Sat, 6 Oct 2012, Reinier Olislagers wrote:<br>
>> On 6-10-2012 6:52, Reinier Olislagers wrote:<br>
>>> Still fighting makefiles with my db fpcunit listener.<br>
</div><snip><br>
<div class="im">>>> Patch including instructions at<br>
>>> <a href="https://bitbucket.org/reiniero/fpc_laz_patch_playground/downloads/dblistener.zip" target="_blank">https://bitbucket.org/reiniero/fpc_laz_patch_playground/downloads/dblistener.zip</a><br>
<br>
</div><div class="im">> Regarding the dbreporter unit itself:<br>
><br>
> I think the explicit dependency on IBConnection is misplaced. What is<br>
> more, it will ONLY work on IB, the way you wrote it. Neither mysql or<br>
> postgres or ms-sql or oracle will eat any of the statements that you use.<br>
</div>I don't really understand that.<br>
<br>
Just confirmed: works fine on PostgreSQL[1] (as you may have noticed<br>
dbwriteraddlist.pas contains a reference to pqconnection).<br>
As far as I can see there's no explicit dependency on ibconnection: when<br>
running with PostgreSQL backend, process monitor shows no Firebird dlls<br>
being loaded (or attempted to be loaded), only PostgreSQL dlls.<br>
pgadmin shows the test results end up in the database.<br>
<br>
Yes, I do need to add the other sqldb units to the uses clause of the<br>
listener class and tell the user in the readme he needs to modify his<br>
own test code uses clause to add non-FPC supplied sqldb units (if any)<br>
in order to load the relevant connector.<br>
<div class="im"><br>
> I would suggest only letting it be dependent on sqldb. It's the duty of<br>
> the user to provide a connection<br>
> class preferably by creating a descendent. You can provide descendents<br>
> for the various TSQLConnection classes in different units, and let the<br>
> user use the unit which uses the connection of his choice.<br>
> (the descendents can also provide 'correct' SQL statements for that<br>
> particular connection)<br>
</div>It is modelled after the db test framework for a reason: it allows easy<br>
setup by testers without having to change code in order to use a<br>
different database backend.<br>
<br>
I see your point about inheritance and actually the code could quite<br>
well be split into a db selection (with support for ini files/db<br>
selection)/manager part, and the core with the rest of the functionality.<br>
DB specific core descendents could be set up if required.<br>
<br>
However, I used simple SQL on purpose in order to make it as compatible<br>
as possible. It shouldn't be necessary to split out the code - but<br>
perhaps tests on other dbs may make that more desirable.<br>
<br>
<br>
<snip><br>
<div class="im">> I have a lot more remarks, which I will not write here in public.<br>
><br>
>> From your zip, it looks like you wanted to submit the unit for<br>
>> inclusion in FPC ?<br>
> I'm sorry to say that, as it is, this unit will not make it in FPC. It<br>
> needs a major redesign from the ground up. I'm prepared to discuss it in<br>
> private, if you're interested.<br>
</div>Having read your private comments I think it could fit in quite well<br>
with FPC with some work, not a total rewrite.<br>
<br>
However, it's not up to me and actions speak louder than words, so let's<br>
wait until I have improved it.<br>
<br>
Regardless of what happens, I'll move the code from my general<br>
repository to one of it's own, together with a recent db test framework<br>
in order to get further feedback from people when running real-world<br>
tests (as well as improvements in adding views/SQL for regression<br>
detection).<br>
<br>
Thanks,<br>
Reinier<br>
<br>
[1] Although fixes like this had to be made for PostgreSQL reporting<br>
"unknown column type"... these fixes work well on Firebird and I expect<br>
them to work elsewhere as well<br>
-      FQuery.Params[1].Clear //null<br>
+    begin<br>
+      FQuery.Params[1].Clear; //null<br>
+      FQuery.Params[1].Datatype:=ftstring;<br>
+    end<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
fpc-pascal maillist  -  <a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/mailman/listinfo/fpc-pascal" target="_blank">http://lists.freepascal.org/mailman/listinfo/fpc-pascal</a><br>
</div></div></blockquote></div><br><br>I have just read this thread and found the points mentioned interesting. I think it would have been better if the points were not discussed in private, that way everyone could learn from it. <br>
<br>Too late though :(<br clear="all"><br>-- <br>Frank Church<br><br>=======================<br><a href="http://devblog.brahmancreations.com">http://devblog.brahmancreations.com</a><br>