[fpc-pascal] Re: Yet more make file problems: make works, make install fails

[Frank Church]

On 10 October 2012 05:35, Reinier Olislagers <reinierolislagers at gmail.com>wrote:

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


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.

Too late though :(

-- 
Frank Church

=======================
http://devblog.brahmancreations.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20121029/871b2f15/attachment.html>