[fpc-pascal] Re: Yet more make file problems: make works, make install fails
vfclists at gmail.com
Tue Oct 30 00:42:58 CET 2012
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.
> >>> Patch including instructions at
> > 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 (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.
> > 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
>  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.Clear //null
> + begin
> + FQuery.Params.Clear; //null
> + FQuery.Params.Datatype:=ftstring;
> + end
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
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 :(
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-pascal