This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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)
Created attachment 31172 [details] image
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.
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.
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
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.
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
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.
The workaround is either - renaming database columns/tables not to use multibyte, or - correcting the generated JSP pages
The waiver is approved.
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.
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
The whole wizard will be dropped from 6.0.
Since there is no JSF from Entity Class wizard from in 6.0, there is no bug, so closing.