different TZConnection classes for diferent sql servers

[lacak.sk]

Hi,
consider please the following situation :
1. I install zeos package, enabling in zeos.inc for
example Interbase and SQLite support, because I plan
develop 2 applications. First is client/server and
uses Interbase and the second is application, that
uses sqlite
2. I build first application, which uses only
Interbase connection, but in application exe file is
linked also support for SQLite /which is not used/, so
size of exe file is larger, than needed.
3. when I build application for sqlite support for
interbase is linked

The solution will be create descendands of
TZConnection for example TZIBConnection,
TZSQLiteConnection, TZPGConnection, ... as separate
components. Then I use in my app only one specialized
type of connection, which I need

[aperger]

Hi


1. As is know the Borland Pascal compiler is a mart compiler. It will link only the needed parts into your program. Use {$IFDEF} please!

2. To create separated TZxxConnection components is not a good idea, because againsts with the menaing of multi DB engine -> handles more and more DB type with the same interface as JDBC under Java!

3. But you can devel it, and you can share it, if you want maybe many develeopers will be happy. :-)

Sorry....

Attila

[lacak.sk]

Hi Attila,

Re1:
the problem is that at design time I need all database support, becasue one time I develop db application for Firebird and at second time for SQLite and then for MySQL.
But when I compile such application support for all databases is linked (due to setting in zeos.inc, where is enabled support for all databases ... this is about 500KB of unneeded code in my real one app).
To work-arround I must before compilink each of my apps do :
1. modify zeos.inc to enable only db support, which is needed for my first (or second or third) app
2. open and recompile zeos package
3. open and recompile my first (or second or third) app

which is little frustrating :-)

Re2:
yes may be, that create sepparate TZxxConnection for each DB falls ou of idea original JDBC, but will lead in more effective (shorer) code.
Because only support realy needed will be linked into application exe file.
In most cases I build app, which is designed for concrete db and so I do not need support for all possible dbs.

Re3:
:-) yes of course. But for core-developers it will be a much simplest task than for me ...

-Laco

[mdaems]

Which core developers do you mean?

As far as I know the original developers are not supporting the project anymore. Somepeople are trying to help us out, but I don't think there are many people left who can be given the title 'Core developer'. So really feel free to implement good solutions.

Concerning your first problem, can you find a way we can change the zeos.inc file so that you can define some compiler switches in your project and force the compiler to recompile zeos units with this setting?

Mark

[lacak.sk]

:-) hm "core developers" ... I refer to people, who are familiar with "core" source code. As I am new to zeos lib, I must study whole source code with dependencies etc. to fully understand it.

I am not sure, if I can supply solution which uses only compiler switches {$DEFINE,$IFDEF etc.}
In common way Delphi package is compiled first and "dcu" are stored in /packages/delphi6/build directory and user apps refers only to this directory and not to directory, where sources are (/src/...)
So
at 1. I must change in my app in Project/Options .../Directories/Search path to D:\zeos\zeosdbo\src\component;D:\zeos\zeosdbo\packages\delphi6\build
at 2. now when I change zeos.inc (enabling/disabling db support using {$DEFINE ...}) change appears in size of application exe file
at 3. when I comment all db support in zeos.inc and add in Project/Options .../Directories/Conditionals e.g. ENABLE_SQLITE only SQLite support is linked into app exe file.
In second app I put ENABLE_INTERBASE so only interbase support is linked.

But this approach is not very clear and transparent.

My preffered solution will be create and register in component pallete beyond TZConnection other specialized TZIBConnection etc. components.
This way uses e.g. Lazarus, which has TIBConnection, TPQConnection, TMySQLConnection ...
In this scenario I drop on form only kind of connection object, which I realy need.

If you agree with this approach, then we can talk about implementation.

-Laco

[mdaems]

Hi,

I'm not sure whether that would enable you to leave out support for other drivers without too much double coding and messing up the layered model.
Also:
- If we want to add these subclasses it should be almost a copy/past job to add the subclasses for newly supported databases. Thecode involvedshouldbe minimal
- It's just an optional feature we're talking about, the main goal is to have database independent components.
- You could give it a try for 1 database driver only, so we could see what is involved for writing such components.

Before adding these components to the package we should check with other users/developers what they think about it. (maintainability, ...) So I can't promise we will actually use your work.

Mark

[noelc]

Does the 500k of extra code linked in really make all that much difference, when that code is never executed? It is not as if we are still in the era of 20MB hard disks! TZConnection works well, and it is generally not a good idea to start fixing what is not broken

[mdaems]

I agree on this!!
However, If Laco needs small exe's and he can proof how easy it is to make these connection component derivates without messing up the general connection component why not add them for who wants them?

Mark

[zippo]

I think the power of Zeos is right the usage of muli-DB whenever you want. And I agree - 500k extra is nothing (my applications are allways about 5-10 Meg).

[lacak.sk]

:-) I started programing 20 years ago, when 64KB of RAM was "standard". So I still understand programing as art of making code as effective (fast and short) as possible.
Also look at this situation from point of view, when there will be for example 10-15 supported DBMS and everhead of unused code will be for example 2MB or 5MB.
Then there will be situation, when I will make little program , which will contain 50% of unused code linked.

In my real example I build a little program using SQLite, when I enable only SQLite support, size is approx. 1MB.
When I leave enbaled support of all DMBS, size is 1.5MB.
This is about 50% more.

I agree, that some users want in one app support for all possible DBMS, but I think, that much more users want support only for 1 or 2 DBMS.
I agree also, that back-compatibility must not be broken.

So the simplest solution (as I see) is :
- create unit for example ZConnectionSQLite.pas :
unit ZConnectionSQLite;

interface

uses
ZDbcSqLite, ZConnection;

type
TZSQLiteConnection=class(TZConnection);

implementation

end.

- then register in component palette TZSQLiteConnection
- then disable support for all DBMS in zeos.inc (which are used in ZConnection.pas)
- then make own application and use TZSQLiteConnection, when I need only support for SQLite
(TZConnection remains as is . Who enables support of DBMS in zeos.inc, still can use TZConnection)

-Laco

[Terence]

I agree to mdaems, if he wants to code this, and then he shall do it for all dbms (nothing or all and it doesn't mess up old architecture, why not.

[lacak.sk]

also lets speak about code that I post .
If it is way or not ...

[lacak.sk]

Or other one short and simple solution may be :
add one unit for one DB connection for example :
unit ZConnectorSQLite;

interface

uses
Classes,ZDbcSqLite;

type
TZSQLiteConnector=class(TComponent);

implementation

end.

This forces initialization part of ZDbcSqLite to register TZSQLiteDriver in DriverManager.
Now when somebody puts on form (or datamodule) TZSQLiteConnector component,
Protocols for sqlite will be available for any TZConnection.

All others units and functionality remain intact.