PgAccess directory structure - Mailing list pgsql-interfaces

I'm not sure how far along the plans for pgaccess are. However,I like to
propose some changes to the directory structure. I would be looking
to have these changes implemented in the main postgres tree if the new
repository isn't operational at the time, as long as that tree is used to
initialise the new repository.


Reason for change (as I see it):

The view seems to be that PgAccess is treated as a separate entity to the main
postgres system. This is a good idea as it enables features to be added without
being tied to a specific version of the backend, amongst other
reasons. However, there is a problem in this in that some parts of PgAccess are
required to be version specific and therefore a single installation of the GUI
can not be used with backends of different version safely. Therefore, older
database users can not gain access to new features unless those are added as
patches to previous releases.

An example is that of the use of views in the reports module. At some stage it
became possible to determine the columns in views and therefore possible to use
them in reports. Obviously prior to that point views were unusable in that
module and so Teo hadn't included them as possible data sources. Adding this
feature now would cause problems when used with for older databases. Although
a defensive ploy here is easy to see I think a better, more flexible scheme is
possible.


Proposal:

That the lib directory gain one level of subdirectories called
Pg<postgres-version>, that code specific to backend version be placed in these
directories and that version independent code by kept in the lib directory.

The backend is interrogated for it's version on the first database connection
and code loaded ondemand from lib/Pg<newest-not-exceeding-interrogated> to
lib/Pg<oldest> and then from lib, with loading stopping at the first file
satisfying the demanded code.

So for example: the Reports namespace (module) would be requested by the line
Reports::build $parent

and the files required to satisfy that code request would be searched for in
the order:
lib/Pg7.3devel/reports.tcllib/Pg7.3/reports.tcllib/Pg7.2.1/reports.tcllib/Pg7.2/reports.tcllib/reports.tcl

Now, it can be seen that if there is any backend version specific code for the
reports module then the nonversion specific code will not be loaded. This is
obviously a bad idea.

One of the ways around this is to note that the existing code loads all the
modules at startup and to do something similar. Given a module name on startup
that module's code can be loaded by calling:<module-name>::Init
where Init may or may not do anything useful apart from causing the code to
load. Backend version specific Init procs would force the load of the common
code for the module by calling:<module-name>::CommonInit
.

An alternative is to do as I have done today and use a convience routine that
loads the common code, via the CommonInit call, and then the version specific
code, via the Init call. This method, although losing the ability to let the
module decide when the common code should be loaded initialised does enable
version specific code to replace and generally override the common code as
needed.

There is a third possible solution using version specific code in a separate
namespace (presumably a subnamespace) to that of the common module code but I
can see some awkwardness with that method and I'm generally less enamoured with
it. Having said that it'd not be too difficult to populate an array providing
version specific name lookup from an unversioned name.

I prefer the second of these schemes, but then I've already coded that so I
could be seen as biased. I would also go ahead a submit these changes for
inclusion in the main postgres tree if I was confident that this wouldn't cause
problems to others currently applying or waiting to apply patches on top of
which this could be seen as a significant change in structure on disk and
therefore really should be done after agreement has bee obtained.

On the subject of pending patches, if this rearrangement were to be
implementated I should imagine that it would be best done after other people's
patches have been applied since there would probably be more work involved in
changing those patches to use this scheme than for this scheme to be placed
into the patched tree. However, this or some other decided upon scheme should
be done _before_ any work goes into producing code that uses features of 7.3,
unless that code is generic enough to work on any version of the
backend. Therefore, I think agreement needs to be reached pretty quickly.


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants