Menu
▾
▴
firebird-devel
|
From: Anton Z. (JIRA) <tr...@fi...> - 2011-11-11 15:55:03
|
Іncrease table name and field name size above 32 symbols
--------------------------------------------------------
Key: CORE-3659
URL: http://tracker.firebirdsql.org/browse/CORE-3659
Project: Firebird Core
Issue Type: Improvement
Affects Versions: 3.0 Alpha 1
Reporter: Anton Zibrov
Іncrease table name and field name size above 32 symbols for support ORM frameworks sach as Ruby on Rails
--
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
|
|
From: Kjell R. <kje...@da...> - 2011-11-13 11:09:28
|
Den 2011-11-11 16:54 skrev Anton Zibrov (JIRA) såhär: > Іncrease table name and field name size above 32 symbols > -------------------------------------------------------- > > Key: CORE-3659 > URL: http://tracker.firebirdsql.org/browse/CORE-3659 > Project: Firebird Core > Issue Type: Improvement > Affects Versions: 3.0 Alpha 1 > Reporter: Anton Zibrov > > > Іncrease table name and field name size above 32 symbols for support ORM frameworks sach as Ruby on Rails > Would be much appreciated, yes. ECO handle's the limitation automatically, but a problem is that the 32 symbol limit is actually a 32 BYTE limit. Since the identifiers are encoded in UTF8, which is variable-length, the actual maximum for a specific identifier depends on the characters it conatains. Very annoying. At least this was the case last time i checked (2.1 I believe). Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Dimitry S. <sd...@ib...> - 2011-11-13 11:14:06
|
13.11.2011 12:09, Kjell Rilbe wrote: >> Іncrease table name and field name size above 32 symbols for support ORM frameworks sach as Ruby on Rails >> > > Would be much appreciated, yes. ECO handle's the limitation > automatically, but a problem is that the 32 symbol limit is actually a > 32 BYTE limit. Since the identifiers are encoded in UTF8, which is > variable-length, the actual maximum for a specific identifier depends on > the characters it conatains. Very annoying. At least this was the case > last time i checked (2.1 I believe). I wonder how such ORM frameworks work with Oracle which has lower name length limit... And why Oracle isn't flooded with such improvement requests. -- SY, SD. |
|
From: Kjell R. <kje...@da...> - 2011-11-13 12:00:57
|
Den 2011-11-13 12:13 skrev Dimitry Sibiryakov såhär: > 13.11.2011 12:09, Kjell Rilbe wrote: >>> Іncrease table name and field name size above 32 symbols for support ORM frameworks sach as Ruby on Rails >> Would be much appreciated, yes. ECO handle's the limitation >> automatically, but a problem is that the 32 symbol limit is actually a >> 32 BYTE limit. Since the identifiers are encoded in UTF8, which is >> variable-length, the actual maximum for a specific identifier depends on >> the characters it conatains. Very annoying. At least this was the case >> last time i checked (2.1 I believe). > I wonder how such ORM frameworks work with Oracle which has lower name length limit... > And why Oracle isn't flooded with such improvement requests. > As I said, ECO handles it automatically. It truncates the ident at maxlength - 3 and appends a three char scrabled suffix that's guaranteed not to create a duplicate ident. So, not really a problem for ECO. But what I wrote about variable length problems forces us to configure ECO to e.g. max 25 chars rather than 31. Also, when working "behind the scenes" directly with the data, the identifiers are sometimes a bit difficult to read/understand, and type of course. So, while it works, it's a bit of a nuiscanse(sp?). Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Alexandre B. S. <ib...@th...> - 2011-11-13 22:50:18
|
Em 13/11/2011 09:13, Dimitry Sibiryakov escreveu:
> 13.11.2011 12:09, Kjell Rilbe wrote:
>>> Іncrease table name and field name size above 32 symbols for support ORM frameworks sach as Ruby on Rails
>> Would be much appreciated, yes. ECO handle's the limitation
>> automatically, but a problem is that the 32 symbol limit is actually a
>> 32 BYTE limit. Since the identifiers are encoded in UTF8, which is
>> variable-length, the actual maximum for a specific identifier depends on
>> the characters it conatains. Very annoying. At least this was the case
>> last time i checked (2.1 I believe).
> I wonder how such ORM frameworks work with Oracle which has lower name length limit...
> And why Oracle isn't flooded with such improvement requests.
>
I don't use ECO or Hibernate, but I already meet a lot of cases where 31
chars is to few to name something, I really like the names spelled
without abreviations it's much easier to remember the full name of
something than the possible abreviations, an example just to show my point:
Quantity_Purchased_Not_Delivered
could be abbreviated to:
Qty_Purch_Not_Delivered
Qt_Purch_Not_Delivered
Qty_Purch_Not_Deliv
Qty_Purchased_Not_Deliv
The case could be even worst when I start to name FK's or Indices
The Default for my FK name is:
FK_Name_of_Parent_Table_Name_of_Child_Table
So if I have I Table named Empresa_Credor_Devedor and another called
Titulo_Pagar the FK named should be
FK_Empresa_Credor_Devedor_Titulo_Pagar wich is not allowed, so I start
to abreviate the name until it fits.
The Indices are named like:
Prefix_Table_Name_Colum_Name
Prefix could be:
AK - for Alternate keys
PK - for Primary Keys
FK - for Foreign Keys
SK - for Secondary Keys
So I could have an index name like:
SK_Empresa_Credor_Devedor_Limite_Credito for a index on
Empresa_Credor_Devedor(Limite_Credito)
SK_Movimento_Estoque_Tipo_Movimento_Data_Numero_Documento for a compound
index on Movimento_Estoque(Tipo_Movimento, Data, Numero_Documento)
of course I could just name everything as
FK_0001
FK_0002
FK_0003
Where an identifier name of 10 chars would be more than enough, but I
really think that's hard to understand a plan where you just see cryptic
index names.
I really don't know if Oracle has a lower limit on the identifier name
than FB, and I don't care, I use FB not Oracle, and this is a FB feature
request to make FB better, just it... I don't think that just because
Oracle has such a limitation it's a good reason to note improve FB...
I understand that such improvement could be hard to implement because of
the changes on the API and that the access libraries must be recoded for
such change, this could be a reason to post pone this modification, but
the argument that the other RDBMS don't support it so we should not
support it either didn't convince me.
I saw this discussion some times, but would not say that it "floods" the
feature request's lists.
I am one who waits for this change, but understand why it's not
implemented yet...
Onve uppon a time ago, I was working on a system that need integration
with People Soft's Bann ERP, the table names are named like:
tm$140
tm$102
tm$235
a query like:
select
tm$140.fwn, tm$140.fwad, tm$102.cn, tm$102.cty
from
tm$140 join
tm$102 on (tm$140.fwid = tm$102.fwid) join
tm$235 on (tm$235.srid = tm$102.srid)
where
tm$102.srn = 'Alexandre'
is a bit more complex to understand than this one
select
f.Name, f.Address, c.Name, c.City
from
Forwarder F join
Costumer C on (C.ForwarderID = F.ForwarderID) join
SalesRepresentative SR on (SR.SalesRepresentativeID =
C.SalesRepresentativeID)
where
SR.Name = 'Alexandre'
Don't you agree ?
best regards,
|
|
From: Adriano d. S. F. <adr...@gm...> - 2011-11-13 23:00:09
|
On 13-11-2011 19:48, Alexandre Benson Smith wrote: > > I understand that such improvement could be hard to implement because of > the changes on the API and that the access libraries must be recoded for > such change, this could be a reason to post pone this modification, but > the argument that the other RDBMS don't support it so we should not > support it either didn't convince me. > In my opinion, DSQL XSQLVAR's should be make as it is now forever. It was done bad, and change it would be bad too. So, it's just a fact of allow it with the new API. And then there must be a way to libraries uses bits of the new API mixed with old one. The increase of it is not difficult. I had it working for true 31-chars UTF-8 names AFAIR. It's unlike that the new limit would be greater than 63 UTF-8 characters, as 64 * 4 > 255 (blr limitation for names). Adriano |
|
From: Alex P. <pes...@ma...> - 2011-11-14 06:54:42
|
On 11/14/11 02:59, Adriano dos Santos Fernandes wrote: > On 13-11-2011 19:48, Alexandre Benson Smith wrote: >> I understand that such improvement could be hard to implement because of >> the changes on the API and that the access libraries must be recoded for >> such change, this could be a reason to post pone this modification, but >> the argument that the other RDBMS don't support it so we should not >> support it either didn't convince me. >> > In my opinion, DSQL XSQLVAR's should be make as it is now forever. It > was done bad, and change it would be bad too. > +1 > So, it's just a fact of allow it with the new API. And then there must > be a way to libraries uses bits of the new API mixed with old one. > May be I do not understand what you mean here... Why mix? > The increase of it is not difficult. I had it working for true 31-chars > UTF-8 names AFAIR. > > It's unlike that the new limit would be greater than 63 UTF-8 > characters, as 64 * 4 > 255 (blr limitation for names). Do we plan to have a special case for ascii? |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-11-14 12:46:51
|
On 14-11-2011 04:54, Alex Peshkoff wrote: > >> So, it's just a fact of allow it with the new API. And then there must >> be a way to libraries uses bits of the new API mixed with old one. >> > > May be I do not understand what you mean here... Why mix? > Because then previously written application would fail in some circumstances. User then will expect a easy fix, but it would need to recode all the Firebird API usage. >> The increase of it is not difficult. I had it working for true 31-chars >> UTF-8 names AFAIR. >> >> It's unlike that the new limit would be greater than 63 UTF-8 >> characters, as 64 * 4 > 255 (blr limitation for names). > > Do we plan to have a special case for ascii? > Why? This is what we have currently no? And it's bad for sure. Adriano |
|
From: Mark R. <ma...@la...> - 2011-11-14 08:52:41
|
On Sun, 13 Nov 2011 20:59:58 -0200, Adriano dos Santos Fernandes <adr...@gm...> wrote: > On 13-11-2011 19:48, Alexandre Benson Smith wrote: >> >> I understand that such improvement could be hard to implement because of >> the changes on the API and that the access libraries must be recoded for >> such change, this could be a reason to post pone this modification, but >> the argument that the other RDBMS don't support it so we should not >> support it either didn't convince me. >> > > In my opinion, DSQL XSQLVAR's should be make as it is now forever. It > was done bad, and change it would be bad too. I am not sure what you mean? XSQLVAR is bad, so we are not going to change it to something (potentially) better? > So, it's just a fact of allow it with the new API. And then there must > be a way to libraries uses bits of the new API mixed with old one. > > The increase of it is not difficult. I had it working for true 31-chars > UTF-8 names AFAIR. > > It's unlike that the new limit would be greater than 63 UTF-8 > characters, as 64 * 4 > 255 (blr limitation for names). UTF-8 is not 4 bytes, each character is encoded with a variable length of 1 to 4 bytes (technically the encoding supports 6 bytes, and some UCS-2 variants of UTF-8 use that instead of two surrogate pairs). Treating a UTF-8 encoded characters as 4 bytes per character is too naive and inefficient: for Western world most characters would occupy 1 byte. Treating it as actually being variable length instead of simply saying 'it's 4 bytes' would allow you to use 63 upto 254 characters, not just 63. BTW: Instead of saying 'it is a limit in BLR', what would be the effort to modify BLR to remove (or increase) this limitation? Mark |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X