Ah, I see! Did not know this was the limitation in Oracle. Now I understand your problem...
Anyway, storing user information to the file system should cause no problems from Slide's point of view. However, when you consider backup and restoring of your repository and half your data is in Oracle and the other half is in the file system this might be non ideal. Hmmmm, what about storing the property value in a blob? Wouldn't this work? Probably a bit slower and maybe a problem for search. However, not when there are indices anyway. Maybe this could be an option? Oliver On Wed, 3 Nov 2004 09:32:57 -0500, Nick Longinow <[EMAIL PROTECTED]> wrote: > This is the size of a single property, such as group-member-set. The size > of the default string value of that property in the shipping slide is about > 188 bytes. If I up the PROPERTY_VALUE VARCHAR2(4000) that is as high as it > can go in Oracle 9x. > > Nick > > > > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 02, 2004 5:24 PM > To: Slide Users Mailing List > Subject: Re: Use Tx store for /users and /roles and DB store for rest ? > > This certainly is possible. However, quoting from what I have found > > "PROPERTY_VALUE" VARCHAR2(255), > > the maximum length of a property value is 255 characters only. But why > not just giving it much more space? Is there any limitation in Oracle? > > I'd recommend to just update the size to what you consider reasonable. > The Slide code itself does not care... > > Oliver > > On Tue, 2 Nov 2004 15:45:24 -0500, Nick Longinow > <[EMAIL PROTECTED]> wrote: > > Is it possible to do this ? I am finding that the column length > limitation > > in Oracle is 4000 characters, which will limit the length of a property > > string in the Properties table. So, you can not update the members of a > > group (ie, users) to have more than about 50 users (given the size of each > > xml fragment representing a user member of the /roles/users group. > > > > Is it possible then to have part of the slide tree go to the Tx store, so > as > > to get around this limitation, and the rest go to a Db store ? > > > > Nick > > > > -----Original Message----- > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Morten > > Sent: Tuesday, November 02, 2004 12:32 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Custom authorization and authentication best practices > > > > lixin chu wrote: > > > Sorry for not giving any anwser - I actually have the > > > same question. > > > > > > I am thinking a third option: let another application > > > handles authentication and authorization. > > > > I'm considering that also. I thought of putting Apache in front, and > > implement it using .htaccess but that doesn't scale well (too hard to > > maintain). > > > > I'm currently toying with an idea of implementing a ServletFilter and > > put that in front of the WebdavServlet, that is a non-intrusive and > > somewhat clean approach where I can consider Slide a shrink-wrap > > standalone product. If it's the best approach I don't know, that's still > > to be determined. But do let me know what you end up doing, I'm curious! > > > > Morten > > > > --------------------------------------------------------------------- > > 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]
