Hi Christopher, > > Jean-Philippe Courson wrote: > >> -> Class org.apache.slide.store.impl.rdbms.J2EEStore should not be >> abstract anymore. > > > Whoa. Fixed :P
Thanks > > >> -> 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? See later > > >> 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. I think that these constraints are not the real problem but that it is the new schema that doesn't take into account versionning related stuff. So removing these contraints will not help in making this store pass the tests, but new schema and store methods have to be modified. > >> 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. Nice idea, but I think like you that optimizations should only be done when store will work ;-) > > >> -> 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. > I would wish to contribute, but I have a big software to be finished in 2 weeks so a lot of work for now. But I will try to help you on evening. Regards Jp -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
