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 it >>stores 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]
