Hi Jean-Philippe, Jean-Philippe Courson wrote: > -> Class org.apache.slide.store.impl.rdbms.J2EEStore should not be > abstract anymore.
Whoa. Fixed :P > -> There is a referential integrity violation on method > removeRevisionDescriptors who tries to remove a revision_history > without removing revision that point to it. > So (if foreign key contraint is ok) revision entry has to be removed > before revision_history one and referenced revision_property entries > are needing too to be removed before. Can you be more specific? > Modifying J2EEStore to do what said above does not help : I got an > ObjectNotFoundException (/users) on slide's initialization. > If JEEStore with old schema is not breaking RevisionDescriptorsStore > I will have to swith back to it for now :-( I have tons of problems with referential integrity violations. For the beginning, I removed all those constraints and tried to make the store pass the functional tests without serious failures. However, even in that I did not succeed yet. Any help would be much appreciated. > While looking at this Store, I has some ideas : > > -> Why is ids cache completely cleared when full ? Don't you think it > would be better to clear only ids not used since a long time and keep > the one most recently used ? Note that keeping records about last-access-time etc. adds overhead too. However, Commons-Collections has a class that we should probably use, LRUMap. > -> It think that table slide_label has not reason to exist. > It is only referenced by slide_revision_label so adding a string > label field to slide_revision_label would avoid to have to perform > one more request (or a join). > I agree that indexes with integers are a lot better than string ones > but this is only usefull for keys used by sql request and not a > reason to add a new table and request for each string data. > There is exactly the same problem with slide_qname table. I can't back this up with numbers, but I think the QNAME table should help a bit on the performance side. Most property names are always the same when Slide is used as a simple DAV server, so there'll be about 12 of them always in the cache. On the other hand, it is probably a premature optimization, and we should try to keep the schema as simple as possible for now. However, priority number one is to get the stuff working :P Again, any help much appreciated. -- Christopher Lenz /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
