Subject | Re: [Firebird-Architect] Re: Database Capabilities |
---|---|
Author | Nando Dessena |
Post date | 2005-07-23T12:27:40Z |
Jim,
J> Firebird 2.0 releases with
J> capabilities not available in first Vulcan release, Jaybird releases
J> with optional support for those features, then Vulcan releases a point
J> release to catch up to Firebird. The problem, then, is that Jaybird
J> can't know that Vulcan now has those capabilities without a re-release
J> of Jaybird.
I see. Well, I didn't think Vulcan would ever be released if not under
the Firebird name, but I guess someone will have advantages by doing
so. Then, I don't think many people will expect JayBird to
automatically support a subsequent release of Vulcan without updating
it (it has never been the case in the past, and lots of people
complain about lots of things about Firebird every day, but I have
never seen anyone complaining that he had to upgrade a connectivity
tool to support new capabilities in a new version of the engine); IOW
it's an ambitious goal and it's probably going to work only
for this brief (the briefer the better, BTW) interlude during which
Vulcan and Firebird are separate things, but I see the point at least.
No objections from me about getting database capabilities with the db
info call. I'm still extremely skeptical about the fact we can do
without something like the "service manager" for more general info
items.
J> you do?
Ask before I create it, so that I know how I am allowed to create it.
J> Personally, I think the idea of database dialect is remarkably
J> dumb, but that's a different question.
It surely is. I'll change example then. Suppose Firebird 2.1 supports
32KB page sizes. I want to know what is the maximum page size for a
database I intend to create. Do I create it with page size = 4KB, then
ask, then drop it and re-create it? I know it's not the best of the
examples, but try to infer my point from it.
Ciao
--
Nando Dessena
http://www.flamerobin.org
J> Firebird 2.0 releases with
J> capabilities not available in first Vulcan release, Jaybird releases
J> with optional support for those features, then Vulcan releases a point
J> release to catch up to Firebird. The problem, then, is that Jaybird
J> can't know that Vulcan now has those capabilities without a re-release
J> of Jaybird.
I see. Well, I didn't think Vulcan would ever be released if not under
the Firebird name, but I guess someone will have advantages by doing
so. Then, I don't think many people will expect JayBird to
automatically support a subsequent release of Vulcan without updating
it (it has never been the case in the past, and lots of people
complain about lots of things about Firebird every day, but I have
never seen anyone complaining that he had to upgrade a connectivity
tool to support new capabilities in a new version of the engine); IOW
it's an ambitious goal and it's probably going to work only
for this brief (the briefer the better, BTW) interlude during which
Vulcan and Firebird are separate things, but I see the point at least.
No objections from me about getting database capabilities with the db
info call. I'm still extremely skeptical about the fact we can do
without something like the "service manager" for more general info
items.
>>the proposal does notJ> As for your second point, create the database and ask? What else could
>>address the problem of knowing the capabilities for a database that
>>doesn't exist yet. Who should I ask whether I can create a dialect 3
>>database or not?
J> you do?
Ask before I create it, so that I know how I am allowed to create it.
J> Personally, I think the idea of database dialect is remarkably
J> dumb, but that's a different question.
It surely is. I'll change example then. Suppose Firebird 2.1 supports
32KB page sizes. I want to know what is the maximum page size for a
database I intend to create. Do I create it with page size = 4KB, then
ask, then drop it and re-create it? I know it's not the best of the
examples, but try to infer my point from it.
Ciao
--
Nando Dessena
http://www.flamerobin.org