Bugzilla is confusing sometimes...
Oliver
Jacob Lund wrote:
I just created an account on bugzilla!
I can see how to create a bug report but I cannot see how to attach a file!
Am I dumber than average or do I need some special rights to attach files?
/Jacob
-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: 29. januar 2004 13:12
To: Slide Users Mailing List
Subject: Re: TXFileStore and local filesystem
The old problem with attachments :( It is missing...
Could you try to create a new bugzilla entry and add the attachment there?
Thanks :)
Oliver
Jacob Lund wrote:
First of all - the patch you just checked in for the txfilestore works
fine
:-)
Some of my problems with the SQLServerAdapter was my fault - forgot to set encoding to UTF-8 in slide.properties.
However to get the SQL store working with Russian and Danish characters at the same time I had to change the database scheme. It turns out that slide does send the Unicode characters to the database but the database scheme user 8bit char in the string fields.
I have attached the new scheme - all I did was change varchar to nvarchar. Now it works fine :-)
/Jacob
-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: 29. januar 2004 10:47
To: Slide Users Mailing List
Subject: Re: TXFileStore and local filesystem
So, I think we have two problems now, I am endangered to mix up:
(1) The filestore has a problem with file names (2) The dabase stores have a problem as well, which is yet unclear to me
Concerning (1): Could you send the new exception after the patch was applied? At least the file name given in the exceptions head followed by "Can not create resource at " should look different for me to see what might be be going on.
Concerning (2): Could you describe this a bit more in order to make my rusty mind understand?
Concerning the Unicode vs. UTF-8 issue: How would you decode a string before storing into the database? Into what? The JDBC method accepts a string, so you will have to pass it one. As I said, you can only decode/encode into/from bytes...
Oliver
Jacob Lund wrote:
The patch did not make any difference - it still throws the same
exception!
What I meant about converting from UTF-8 to Unicode is that the database driver can handle Unicode. In the filestore UTF-8 is converted to local character set in order to create the files and this is why the filestore
(I
think) has a problem. If the database could store the data in Unicode then there would be no problem. Since java is using Unicode in strings the task would simply be to decode the strings before they are stored in the
database
and then make sure that all text fields in the database are Unicode (or widechar or nchar).
Please tell me if I am way off here!
/Jacob
-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: 29. januar 2004 10:02
To: Slide Users Mailing List
Subject: Re: TXFileStore and local filesystem
Jacob Lund wrote:
No, the filestore works correctly.
OK, shall I check in the patch? Did it work for you?
From what I can see the filestore converts from UTF-8 to local before itstores data. This I why UTF-8 works fine for me when I upload files with Danish letters in the filename, and also why if fails when it stores
files
with characters not supported by the codepage.
Windows XP use Unicode, but in "dos mode" it will use the old codepage types. The only thing that I can imagine is that java will use this
codepage
when it is doing IO operations towards the filesystem. This problem might
be
a problem that only appears on windows systems.
I do not think that the problem is in the fill data into the database
that
has a problem. Some place in slide it will convert that data (in this
case
the uri) to UTF-8 before it is send to the client. The data stored in the database is UTF-8, and I believe that java is using Unicode. So the
solution
might be to convert data fetched from the database back to Unicode as
soon
as it arrives to the store class.
The correct solution might be to convert from UTF-8 to Unicode before storing the data and then change the database scheme to Unicode char in
all
fields containing strings.
Hmmmm. You might be confusing certain things here. On one side there is Unicode having a number for each character. On the other side there is the representation in bytes. Now, UTF-8 *is* Unicode, but on the other side, i.e. the representation in bytes. Thus it does not make too much sense to compare Unicode with UTF-8. Do you agree?
I am guessing here since I do not have any idea of how the stores are structured in slide. I you want I would be happy to do some debugging,
but
I
will need a short introduction to how the datastores are designed in
slide.
I know, proper documentation is a major problem. I will try to prepare something like a short introduction and will post it to the list as soon as it is done. This may take a while though :(
Oliver
/Jacob
-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: 28. januar 2004 16:40
To: Slide Users Mailing List
Subject: Re: TXFileStore and local filesystem
Jacob Lund wrote:
Sorry about that - yes I am talking about the URI!
If I look in a record in the database, each Danish character is stored
as
two "funny looking" characters corresponding to the unescaped UTF-8
encoded
version - so this looks correct! However when I do a propfind on the collection I which I place this file, then I get something like this /files/%C3%83%C2%B8 - and this should have been representing one Danish character. If I take the above and convert from UTF8 to my local, then I
get
what is store in the database - If I then convert from UTF8 to local
again
the I get the correct Danish letter.
I could not find anything that might have converted the URI strings. They are just plainly filled into the SQL like in
"select 1 from OBJECT o, URI u where
o.URI_ID=u.URI_ID and u.URI_STRING=?");
statement.setString(1, uri.toString());
So, maybe this is a more general problem...
I seem that slide converts the URI's from the db to UTF8, but they are already stored in unescaped UTF-8!
Does this happen with the file store as well?
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
