Hi Adriano,
I was thinking about this - the issues are more complex when you take into
consideration the ideas of schema.
I was looking at the issue and was trying to consider the best path forward.
The options I saw where as follows
1. Extend the name, let the user correct the ddl before upgrading, make
the name as long as the longest supported index-able UTF8 string, stop
reading emails when people complain.
2. Keep the short name and create another column that holds a longer
name. Extend the create/recreate syntax to allow for defining a longer
name. If the user did not define a longer name, use the short name.
(lots of possible little gotcha's in this method).
3. Try something new.
When looking at (3) I wanted to understand just what was wanted/needed in
this day and age.
- Databases have become international, we support character sets but, a
name defined in english is always in english, no option to have multiple
names for a sql object. In Canada with bilingualism, if we create a
database and a user with excel/odbc connects directly to the database, the
object names/columns may not be in a language the user can understand.
- Firebird does not support schema or having database connections
defined as part of the metadata (most major database engines support schema
while some such as oracle allow for linking remote schema into the local
metadata)
- Some client applications (ODBC limit of 128) can't handle extreamly
long identifiers which can be troublesome (never ask the welsh to name
something)
I am thinking that the engine needs to switch to surrogate keys for object
naming (using an iterator or uuid for objects in the system tables) while
having a lookup/reference table that the parser uses.
For example
Table RDB$EXTENDED_OBJECT_NAMES(
RDB$OBJECT_TYPE integer,
RDB$OBJECT_LANGUAGE varchar(128),
RDB$OBJECT_PARENT varchar(128),
RBD$OBJECT_LEGACY_NAME char(31),
RDB$ACTUAL_NAME)
The above is very rough but, the short concept is, you have a recursive
tree structure that is used to hold any name in any language with multiple
sql names pointing to the same real database object. In effect, the user
no longer sees the real sql object name inside the database but can have
names in any language.
This would also allow users to use name spaces (schema) or if in the future
we want to, we could setup an entire remote database to appear to be a
schema tree in a master database.
The Legacy name column would allow for older clients to support the new
structure.
The database would have to be created with a default language which is used
unless the client requests a different language on connection.
The database/user would need to have a default schema to allow for clients
that do not request/use schema.
Just an idea.
best regards
Dalton
On 3 June 2016 at 09:11, Adriano dos Santos Fernandes <adrian...@gmail.com>
wrote:
> Hi!
>
> I started patch for longer metadata names and at the same time changing
> UNICODE_FSS to UTF8 in system tables and also changing the byte-limit to
> character-limit in them.
>
> The major thing to discuss here is, what should be that character limit:
> 64, 128, other?
>
> Older than v4 tools (isql, gbak) connecting to v4 server should not work
> correctly only when dealing with longer than 31 characters names.
>
> ISQL commands that display things in columns (for example, SHOW TABLE)
> must be changed to print each item per line.
>
> There is the problem of how names (sqlname, relname, ownname, aliasname)
> will be represented in XSQLVAR which uses [32] arrays. By default (old
> clients) longer names will be truncated there.
>
> I do not think modern applications depends on these entries. It also
> lacks package name now and nobody noted.
>
> I treat this problem as low priority, but supposing we're going to do
> something to users of the legacy API access longer names, I think the
> best method is to have a function that obtains an IStatement from an
> isc_stmt_handle and read them with the new API.
>
>
> Adriano
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
