Re: [Firebird-devel] Longer metadata names and related things
Adriano dos Santos Fernandes wrote: > On 03/06/2016 10:35, Geoff Worboys wrote: >> This is not a request, I am just asking whether the option >> has been considered as a way of maintaining backward >> compatibility. > Not considered nor will. > No reason to introduce such things for so small and easy to > fix problem with is not even a problem if they do not use > longer names when they can't support. Can I suggest then, that you implement a database option and/or a server option that controls the acceptance of long metadata names. Databases could upgrade with the option set to deny long names. This would help to ensure that people don't get themselves in the situation of accidentally shutting out their existing database tools (eg: submitting a script with an unnoticed extra character in a name). Indeed, such an option could let developers manage the maximum length of the names they want to support. You could implement support for 255 in the metadata tables, but default the limit to 128 for new databases ... or something like that. Just a thought. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Longer metadata names and related things
>> I'd prefer to introduce XSQLDA version 2. >Then it should also include schema name (reserved now), to avoid yet another version switch in the future. And package name ... Dmitry Kovalenko www.ibprovider.com -- 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
Re: [Firebird-devel] Longer metadata names and related things
03.06.2016 16:22, Dmitry Yemanov wrote: > Then it should also include schema name (reserved now), to avoid yet > another version switch in the future. Sure. May be even open-ended set of XSQLVAR properties is possible if designed carefully. But there is no rush to design it right now. -- WBR, SD. -- 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
Re: [Firebird-devel] Longer metadata names and related things
On 03/06/2016 10:35, Geoff Worboys wrote: > This is not a request, I am just asking whether the option has > been considered as a way of maintaining backward compatibility. Not considered nor will. No reason to introduce such things for so small and easy to fix problem with is not even a problem if they do not use longer names when they can't support. 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
Re: [Firebird-devel] Longer metadata names and related things
Adriano dos Santos Fernandes wrote: ... > Older than v4 tools (isql, gbak) connecting to v4 server > should not work correctly only when dealing with longer > than 31 characters names. ... Have you considered (and perhaps rejected) supporting both old and new through the use of some sort of short-name alias? Sort of like the way Windows continues to support short names. Old applications still work, they just got names that weren't all that user friendly. This is not a request, I am just asking whether the option has been considered as a way of maintaining backward compatibility. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
[Firebird-devel] [FB-Tracker] Created: (CORE-5259) Problem of lower() and upper() commands
Problem of lower() and upper() commands
-
Key: CORE-5259
URL: http://tracker.firebirdsql.org/browse/CORE-5259
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5.5
Environment: Windows
Reporter: Saber Da
Priority: Critical
When i use lower() and upper() commands for persian language receive this
result:
select lower('علی') from MON$DATABASE>> ْلي
select upper('علی') from MON$DATABASE>> عءح
and this not be correct. Please check this problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
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
Re: [Firebird-devel] Longer metadata names and related things
03.06.2016 16:30, Dimitry Sibiryakov wrote: >> 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. > > I'd prefer to introduce XSQLDA version 2. Then it should also include schema name (reserved now), to avoid yet another version switch in the future. Dmitry -- 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
Re: [Firebird-devel] Longer metadata names and related things
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_TYPEinteger, 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 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. Ma
Re: [Firebird-devel] Longer metadata names and related things
03.06.2016 15:11, Adriano dos Santos Fernandes wrote: > The major thing to discuss here is, what should be that character limit: > 64, 128, other? From MSDN: "SQL_MAX_IDENTIFIER_LEN(ODBC 3.0) An SQLUSMALLINT that indicates the maximum size in characters that the data source supports for user-defined names. An FIPS Entry level–conformant driver will return at least 18. An FIPS Intermediate level–conformant driver will return at least 128." I think that 128 is a good compromise. > 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. That's ok, but make sure that they are truncated to whole character, not just byte. > 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. I'd prefer to introduce XSQLDA version 2. -- WBR, SD. -- 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
[Firebird-devel] Longer metadata names and related things
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
Re: [Firebird-devel] BLR contexts limit
03.06.2016 10:09, liviuslivius wrote: > > PS. why this is not compatibile? I can think about procedures and triggers > but alredy existing triggers and procedures have not more then 256 contexts. > This can not be changed as version number in blr? New BLR version (e.g. introduced in v3.0.1) will not be understandable by the v3.0.0 engine. But ODS 12 promises that the databases are compatible among all v3.x builds, both backward and forward. We can add such changes only in major FB versions. Dmitry -- 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
Re: [Firebird-devel] BLR contexts limit
Hi, sadly to hear about v3. But good to see that this is in progress :) Thanks for the info. PS. why this is not compatibile? I can think about procedures and triggers but alredy existing triggers and procedures have not more then 256 contexts. This can not be changed as version number in blr? regards, Karol Bieniaszewski W dniu 2016-06-03 08:11:53 użytkownik Dmitry Yemanov napisał: > 03.06.2016 09:04, liviuslivius wrote: > > > > is something done in the subject? Or some info about plans :) > > I tested current FB3 snapshot but still context limit :( > > "Dynamic SQL Error. Too many Contexts of Relation/Procedure/Views. Maximum > > allowed is 256.". > > It won't be done in v3.x, this change is not backward compatible. > So it will be committed (this month, I hope) into v4 only. > > > Dmitry > > > -- > 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
