Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 152486 - [65cat] SQL History: if running NB in multiple locales the history file cannot be parsed
[65cat] SQL History: if running NB in multiple locales the history file cann...
Status: VERIFIED FIXED
Product: db
Classification: Unclassified
Component: SQL Editor
6.x
All All
: P2 (vote)
: 6.x
Assigned To: John Baker
issues@db
65fixes1-verified
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-06 08:12 UTC by John Baker
Modified: 2008-12-11 22:29 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Updated changeset which cleanly applies on release65_fixes repo. (12.30 KB, patch)
2008-11-18 15:11 UTC, rbalada
Details | Diff
Log file... (14.66 KB, application/x-gzip)
2008-11-18 19:28 UTC, Michel Graciano
Details
History file from 6.5 RC2 (280 bytes, application/x-gzip)
2008-11-18 21:01 UTC, Michel Graciano
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Baker 2008-11-06 08:13:00 UTC
If in another NB session, I change locales and try to view SQL History, the dialog may open empty.
The reason is the date when the SQL was executed is saved in a format for the system locale.

e.g. 
first session, the date executed is saved in the format DD-MM-YYYY
in another session, DateFormat doesn't parse DD-MM-YYYY.  Instead, maybe MM-DD-YYYY was expected.

Instead of saving a date, the timestamp in milliseconds can be saved.
Comment 1 John Baker 2008-11-06 08:16:45 UTC
Steps to reproduce:
1) Run NetBeans in some locale 
2) Execute some SQL statements
3) Exit NetBeans, change locale, restart NetBeans
4) Try to open SQL History

dialog opens empty, instead should see statements executed
Comment 2 Michel Graciano 2008-11-06 11:55:49 UTC
BTW, any chance to see it on a patch for 6.5? I am really afraid to lost my history time after time.

Regards
Comment 3 Michel Graciano 2008-11-06 11:58:09 UTC
I just updating it for DEFECT since it is a problem, which cause data loss.
Comment 4 Roman Mostyka 2008-11-06 15:34:00 UTC
John, I marked this issue as candidate for Patch 1.
If you think that we won't be able to fix this issue till 10 November, please remove status whiteboard.
Comment 5 John Baker 2008-11-07 01:49:44 UTC
98a2eb9ab661
Comment 6 John Baker 2008-11-07 01:54:46 UTC
Once fix is available, previously executed statements won't be retained if they the date fails to parse (due to changing
locales)

After using a build with this patch, from then on, statements will be saved even if changing the locale 
Comment 7 Roman Mostyka 2008-11-07 08:49:54 UTC
hmichel, can You verify that this issue was really fixed?
Please update this issue according to your results.
Thanks.
Comment 8 Michel Graciano 2008-11-07 12:47:00 UTC
Which build could I use?
Comment 9 Quality Engineering 2008-11-07 16:19:38 UTC
Integrated into 'main-golden', will be available in build *200811071401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/98a2eb9ab661
User: John Baker <jbaker@netbeans.org>
Log: #152486 fix by persisting time in milliseconds
Comment 10 John Baker 2008-11-07 16:59:12 UTC
> Integrated into 'main-golden', will be available in build *200811071401* on http://bits.netbeans.org/dev/nightly/
(upload may still be in progress)

I think the build will be available in 7-8hhrs, by 16:00
Comment 11 rbalada 2008-11-18 11:54:13 UTC
Please verify this issue so it can be included in NetBeans 6.5 Patch1
Comment 12 rbalada 2008-11-18 15:11:08 UTC
Created attachment 73870 [details]
Updated changeset which cleanly applies on release65_fixes repo.
Comment 13 John Baker 2008-11-18 16:14:33 UTC
hmichel could you please verify that this has been fixed  by installing a nightly build 
http://bits.netbeans.org/download/trunk/nightly/latest/

Thank you
Comment 14 Michel Graciano 2008-11-18 19:16:36 UTC
No, it is not fixed. I got the attached exception. BTW, this exception just freeze the IDE and I needed to kill the IDE
process. The problem is that I have a sql_history.xml file in the correct folder (imported by IDE during first start)
and I can't see it anymore. The UI is clean when I open the SQL history. BTW, I just changed the IDE initial parameter
to start with --locale en:US, and the history file I think was created in the pt:BR locale. The UI should be able to
parse the history file already create, imagine the users using the IDE in different locales and now running this with
the patch 1 or if the user copy the userdir for another workstation with different locale, this MUST work, the history
must be available. Maybe the FCS should store this data always in a specific locale to avoid this kind of regression
with the patch or next release.
Comment 15 Michel Graciano 2008-11-18 19:21:36 UTC
I increased to P1 since it causes data loss. Just to be clear, all the data in userdir, AFAIK, must not be locale
dependent, so, I can copy these data from an workstation to another, or share this folder on my network, and be able to
use it in any workstation I need. So, if it is not possible, we have another P1, since user lost data.
Comment 16 Michel Graciano 2008-11-18 19:22:26 UTC
Product Version: NetBeans IDE Dev (Build 200811170201)
Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15
System: Linux version 2.6.27-8-generic running on i386; ISO-8859-1; en_US (nb)
Userdir: /home/hmichel/.netbeans/dev
Comment 17 John Baker 2008-11-18 19:22:49 UTC
This fix enables switching locales.
Use case that was fixed is ..

1) Run NetBeans in some locale 
2) Execute some SQL statements
3) Exit NetBeans, change locale, restart NetBeans
4) Try to open SQL History


The fix doesn't deal with moving the userdir or importing.  That would be a separate issue.
However, NetBeans probably wouldn't work if the user moved the userdir to another computer since the paths to settings
may be different.
Comment 18 John Baker 2008-11-18 19:23:52 UTC
If you think the userdir should be moved to another computer, please file a separate issue.

Let's just deal with one thing at a time
Comment 19 John Baker 2008-11-18 19:25:13 UTC
I don't see the new stack trace attached.
Comment 20 John Baker 2008-11-18 19:26:17 UTC
Please verify the use case without moving the userdir 

1) Run NetBeans in some locale 
2) Execute some SQL statements
3) Exit NetBeans, change locale, restart NetBeans
4) Try to open SQL History

Comment 21 Michel Graciano 2008-11-18 19:28:21 UTC
Created attachment 73882 [details]
Log file...
Comment 22 Michel Graciano 2008-11-18 19:29:09 UTC
Now it is attached. :)
Comment 23 John Baker 2008-11-18 19:45:45 UTC
From the exception, it appears no SQL history was found - but this was after you moved the userdir to another computer?
Comment 24 Michel Graciano 2008-11-18 19:58:39 UTC
No, this happens when I import the settings from 6.1 version, which has no sql history support since it is a 6.5 feature.
BTW, I tested with daily build and everything works fine, but, if I generate a history file on 6.5 RC2 in pt:BR locale,
copy it for daily build user folder, run the IDE daily build in en:US and click on Apply button, I had this exception too.
Comment 25 John Baker 2008-11-18 19:59:46 UTC
I marked this a fixed again please verify the use case by using one computer and not moving the userdir

Please verify the use case without moving the userdir 

1) Run NetBeans in some locale 
2) Execute some SQL statements
3) Exit NetBeans, change locale, restart NetBeans
4) Try to open SQL History

Thank you very much
Comment 26 Michel Graciano 2008-11-18 20:04:46 UTC
This use case works really fine, since now you store it as milliseconds, it works for any locale. I am really afraid
about parsing files from FCS version, since this fix is just for patch 1.
Comment 27 John Baker 2008-11-18 20:17:36 UTC
Regarding parsing the history file from FCS, you can try, but when changing locale, the history may get cleared.
But there is no solution to retaining the history if you change locales.

If the locale is kept the same then history from FCS should still be retained when using the 6.5 patch 1
Comment 28 John Baker 2008-11-18 20:18:25 UTC
I forgot to mention since the use case passes, please mark this issue as verified
Comment 29 Michel Graciano 2008-11-18 21:00:05 UTC
Just confirm it to me, the RC2 history file is the same that, in theory, FCS will generate? If yes, see the following
use case:
1- Run some SQL statements on 6.5 RC2 in pt:BR locale;
2- Run some SQL statemets on daily build, just to create the folders on user folder;
3- Close all IDEs, and copy the history file from RC2 to daily build
4- Open daily build IDE and click on Apply button.

You will see your IDE frozen and the exception I told you should be thrown on your messages.log file. If you think it is
a valid use case, as I think, this issue should be reopened. Just in case, I will attach my RC2 history file.
Comment 30 Michel Graciano 2008-11-18 21:01:13 UTC
Created attachment 73885 [details]
History file from 6.5 RC2
Comment 31 Michel Graciano 2008-11-18 21:07:34 UTC
Just to be clear, I don't agree with the approach decided here, where the history file is lost, or cleared if you
prefer, if the locale is changed. For me it is a bad design and should be fixed, but I know, sadly, that this kind of
issue will not stop the release, otherwise this kind of issue IMO is a P1 with the follow reason: user just can't trust
in the tool.
Comment 32 John Baker 2008-11-18 21:36:46 UTC
Oh I see! you just copied the sql_history.xml file.  I thought you copied the whole userdir to another computer.

I tried your use case and can reproduce.
As I mentioned, unfortunately, the history file from R2 won't be recoverable for patch 1  the java.util.Date cannot
be parsed if locale is changed.  

I might be able to replace the unparsable date with the current date.  If this works then the history file shouldn't be
lost.

But, if you create the history file in patch 1 and switch locales then the history file should be retained and usable.

When clicking the Apply button, I did reproduce the IDE freezing.

I can reopen and try to improve the fix
Comment 33 John Baker 2008-11-18 21:58:54 UTC
#672be402371c improved fix - set date to current timestamp if date is not parsable
Comment 34 Michel Graciano 2008-11-18 23:37:59 UTC
Hi John,
I tested the patch sent by mail and everything works as described. Now I think we have a good fix.
Thanks for your good work and quickly reply. Just fix this issue and I will mark this verified in the next build.

Regards.
Comment 35 Michel Graciano 2008-11-18 23:44:36 UTC
John,
just to answer your previous message, Yes, I copied the whole userdir too, I tested just switching locales and so on,
and every this scenarios had the same result, so, I just sent you the easiest to reproduce. I will test the patch again
with all scenarios is possible, but I really think it was fixed.

Regards
Comment 36 Roman Mostyka 2008-11-19 14:09:40 UTC
hmichel, can You take a look at this issue? This issue is P2 and is going to be included into NetBeans 6.5 Patch 1.
Please make it VERIFIED till 27 November or update this issue with justification why the fix doesn't work till this date.
Thanks.
Comment 37 Michel Graciano 2008-11-19 14:58:41 UTC
Could you point me out the correct build for tests? By default, I always wait for qa message about which build the issue
is available.
Comment 38 Quality Engineering 2008-11-19 16:44:06 UTC
Integrated into 'main-golden', will be available in build *200811191401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/672be402371c
User: John Baker <jbaker@netbeans.org>
Log: #152486 improved fix if date is not parsable, use current timestamp
Comment 39 John Baker 2008-11-19 20:51:26 UTC
fix should be in this build http://bits.netbeans.org/download/trunk/nightly/2008-11-19_14-01-51/

(Issue shouldn't have been reopened)
Comment 40 Michel Graciano 2008-11-20 14:57:37 UTC
v. 200811200201

For me now it is safe to be merged with patch1 branch.
Comment 41 rbalada 2008-11-20 21:39:30 UTC
I've ported the changeset http://hg.netbeans.org/main/rev/98a2eb9ab661 into release65_fixes repository as
http://hg.netbeans.org/release65_fixes/rev/76c3c21de71f
I've transplanted the changeset http://hg.netbeans.org/main/rev/672be402371c into release65_fixes repository as
http://hg.netbeans.org/release65_fixes/rev/c790cdec96cd


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