Bug 78286 - I18N - entity class with mbyte name (= table name) does not work
I18N - entity class with mbyte name (= table name) does not work
Status: RESOLVED INVALID
Product: javaee
Classification: Unclassified
Component: JSF
5.x
Sun All
: P3 (vote)
: 6.x
Assigned To: Andrei Badea
issues@javaee
: I18N
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-19 20:21 UTC by Ken Frank
Modified: 2007-11-05 16:39 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
image (50.69 KB, image/gif)
2006-06-19 20:23 UTC, Ken Frank
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2006-06-19 20:21:41 UTC
assumption here, for oracle at least (not clear about derby) is that table and
column names can have multibyte in them (using mbyte as the first characters of
these) and from dbexplorer, such tables can be created and queried.


But in doing the process
create entity class (giving mbyte as class name which later becomes new table name)
and then jsf pages from entity class,
the browser appears with the class name, but choosing that table name shows
error msg in browser (see attached) I don't see exception in ide log file.

Note that entity class with en class name, which means en table name
does work, even if a column name has mbyte.

and we have not seen problems yet with mbyte in actual data.

NOTE - due to the other bug about the jsp files not showing the mbyte
correctly (after jsf page generation), you need to fix these first
using the correct mbyte - i use the ide's find/replace for quick fixing
for this workaround.


(But creating entity class from dbase, where dbase has a table with
mbyte as table or even just col name, gives a different kind of problem,
and will be filed separately)
Comment 1 Ken Frank 2006-06-19 20:23:52 UTC
Created attachment 31172 [details]
image
Comment 2 Pavel Buzek 2006-07-12 19:17:25 UTC
I assume the problem is that the generator uses table name for a folder name
which in turn is being used as a URL and this last part does not work. Any
suggestions for how to solve this? Would it be acceptable to generate different
folder name? Or should I try to escape the string used for URL so that it could
point to the folder with multibyte name (is that possible)? Thanks for any ideas.
Comment 3 Andrei Badea 2006-07-13 21:38:56 UTC
I can't think of a way to reliably generate a meaningful folder name. Replacing
non-us-ascii characters with _ would probably not work for names in which all
characters are non-ascii (Chinese, etc.).

URL-encoding the folder names using UTF-8 as the character-to-byte encoding
would be better if it proves to work. UTF-8 is not specified by the HTTP 1.1
spec as the default request encoding (no encoding is, so at least some servers
will use ISO-8859-1). I have no idea if if the servers we support use UTF-8 when
parsing the request.
Comment 4 Ken Frank 2006-07-17 22:29:34 UTC
Addtional info -

the table is created in the dbase however (at least for derby) , and data can be
added to it
(mb table name, en col name in this case, since this issue is about table names,
not col names, see 78303 for one about that.

ken.frank@sun.com
Comment 5 Petr Jiricka 2006-09-18 10:18:23 UTC
Hi Ken, how important is to fix this for NetBeans 5.5? Is it a common scenario
to have multibyte table names in a database? Do all databases support this, and
which ones do not? Thanks.
Comment 6 Ken Frank 2006-09-18 17:33:08 UTC
Answering Petr's questions from other comments:

"Hi Ken, how important is to fix this for NetBeans 5.5? Is it a common scenario
to have multibyte table names in a database? Do all databases support this, and
which ones do not? Thanks."

As to use of mbyte in table/column names, I think as we get a wider audience for
the fucntionality, there will be more users in other countries and thus more
that will want to use mbyte in table or column names (the topic of this bug and
other related one is column names, which I think would be more used).

That is, table and column names are often chosen to relate to the data
in them, and since we know data can and are having mbyte, and if the
dbase itself supports mbyte in table and/or column name, then nb should
also. (we see that at least oracle and javadb allow this, think that others
do but would need to look at it but that shouldn't block this issue since we
know at least these 2 db allow it and are 2 of our supt db)

(also, it is legal in java to have class name with mbyte in it;
so by not allowing table name with mbyte, it is a restriction on
use of java.

Thus I think that it will be helpful to fix this.



ken.frank@sun.com


Comment 7 Petr Jiricka 2006-09-19 12:58:13 UTC
Ok, so it sounds like this is something that people may in the future
potentially do, but we don't have current real world examples of databases with
multibyte column/table names. 

Also, since this is a difficult and time consuming fix, and the desired solution
is not clear, I am requesting a waiver for this issue.
Comment 8 Petr Jiricka 2006-09-20 14:01:49 UTC
The workaround is either
- renaming database columns/tables not to use multibyte, or
- correcting the generated JSP pages

Comment 9 Petr Jiricka 2006-09-22 11:15:51 UTC
The waiver is approved.
Comment 10 Andrei Badea 2007-06-19 10:22:28 UTC
Downgrading to P3, since this hasn't have any duplicates so far, and the user impact is low. Not clear what the right
solution is, but it probably needs to use FileEncodingQuery. 
Comment 11 Ken Frank 2007-06-19 15:44:43 UTC
how about not allowing mbyte as the class name, with a warning in the wizard on that pane 
and not allow wizard to proceed until class name does not have multibyte ?

This seems to be easier kind of fix and allows to avoid the problem and if there is additional
user input, then actual fix could be considered.

ken.frank@sun.com

Comment 12 Andrei Badea 2007-06-19 17:39:18 UTC
The whole wizard will be dropped from 6.0.
Comment 13 Andrei Badea 2007-11-05 16:39:05 UTC
Since there is no JSF from Entity Class wizard from  in 6.0, there is no bug, so closing.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo