|Re: [IB-Architect] Database names
> >What did you think of the architecture that I described the other day, inThe need is that folks have a need for a certain set of "staple" UDFs in
> >which functions could be declared globally in the config file ...
> Personally, I don't see the need. Obviously, some people do. Could
> they explain the problem with the current scheme?
nearly every database. Strlen, Rtrim, DayOfMonth, stuff like that. Folks
(including myself) find it repetitive and seemingly unnecessary to declare
commonly needed UDFs in every database.
> Perhaps there isYes, we do have an include mechanism for isql (the "input" command), but
> a simpler solution such as DDL includes to pick up a common system
that's still an extra step that one has to remember to do. The proposed
solution would enable _all_ databases on a system to have access to a
certain set of common UDFs _without_ having to declare them all.
> Something I built into the DDL processor on my current program isThat's neat. Would solve some people's schema maintenance tasks.
> an "upgrade" DDL verb parallel to "create" (Oracle has the same
> I really prefer exploring modest extensions before jumping intoMaybe isql needs a "~/.isqldefaults" file for commands to run automatically
> a radical change. Sometimes radical changes are necessary.
upon startup (I think qli always had this) or when certain other statements
are invoked, such as CREATE DATABASE. Then one could define a set of
DECLARE EXTERNAL FUNCTION statements to run automatically every time one
creates a database.
> Golly, Bill, are you trying to reinvent the registry? Do you haveHey! Not a bad idea. Perhaps it's something I could do, and offer as a
> any of idea of what those Linux guys are going to do with you when
> they catch on?
freeware package on www.karwin.com as a project unrelated to InterBase...
> Seriously, consideration of a configuration file should start withI think it's been made clear that there are many other things one could put
> the need. So far we've agree that something needs to record database
> mappings. Let's try to agree on what else makes sense before we try
> to figure out the implementation.
in this config repository (whatever the mechanism). Like everything that's
currently in isc_config, and the authentication plug-in information, etc.
> File shares is something NT does pretty well. You don't have to beGood point. I hadn't thought of that, because I assume that InterBase
> on the console to edit the file.
server directories should never be shared, for security reasons.
> >The suggestion I made earlier was that every time a module in the serverthe
> >requests a config item from the config cache, the config manager stats
> >config file and refreshes the cache if needed.Neither do I like this method. Forcing inetd to re-read its configuration
> This isn't consistent with Unix practice, which is to reparse only
> when requested (usually with a HUP signal). For the record, I don't
> like this either (I'm hard to please).
with a HUP signal is a nuisance. That's why I suggested the server re-read
the config file automatically when the timestamp changes, but not until some
module in the server requests a config item.
This would of course be simpler if the config information were kept in
system tables where possible.
> XML is the fad of the hourI'm not necessarily married to XML. (okay, I do have some equity in it ;)
I just thought that *if* InterBase uses a flat config file implementation, a
well-known structured text standard is probably preferred over a propriety
> A blob in a system table with an Apache-likeDoesn't it kind of defeat the purpose of storing the config information in a
> configuration string that specified the module and supplied parameters
> would be dandy.
database if you're going to store it as a textual representation in a Blob.
You can't query or set individual elements with SQL statements. Your
version control is all-or-nothing. If you provide syntax validation, you
have to build it into the server. You lose the accessibility of editing the
config with vi. You also need a front-end tool (either isql or a
specialized tool) to view the configuration if you just want to simply check
> >> I would like the first authentication plug-in be support for isc4.gdblists.
> >> ...we can back away from it in favor of Apache style authentication
> >Sorry, this wasn't what I was getting at. I just meant that it was logical
> >You mean for each given database Alias, declare a potentially different
> >authentication repository? Sounds great.
> Sorry, no. I want [the] configuration stuff in a blob in the database.
for authentication details to be associated in some way with a given
database Alias. It's not necessary that these details are stored in an
external config file, even if Alias mappings are.
For example, if the authentication details are stored in the database, then
the sequence might be:
1. The Y-Valve maps an alias to a database file, and the engine readies the
database with no authenticated InterBase user ID set.
2. The access method finds authentication info in the database's system
tables, and connects to the authentication server.
3. Identify and authenticate the user. If successful, set USER
appropriately and proceed to allow requests. If unsuccessful, return
authentication error message and disconnect from database.
Another neat option that the authentication-per-Alias provides is that one
could theoretically configure multiple Aliases that point to the same
physical database, and each Alias would have a different authentication
scheme! That is,
CONNECT 'dbserver:Employeegdb_NIS' USER 'root';
CONNECT 'dbserver:Employeegdb_ISC4' USER 'sysdba';