You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Jean-Philippe Courson <co...@noos.fr> on 2002/09/01 13:03:58 UTC
J2EEStore problems and ideas
Hi,
Testing J2EEStore with new db schema shows me some problems :
-> Class org.apache.slide.store.impl.rdbms.J2EEStore should not be
abstract anymore.
-> 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.
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 :-(
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 ?
-> 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.
Regards
Jp
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: J2EEStore problems and ideas
Posted by Jean-Philippe Courson <co...@noos.fr>.
Hi,
I found that branches hierachy seems to be lost.
Hope that help
Jp
> Ashok is now away for a few weeks, so he will not be able to have a look.
> Versioning was not included when the new schema was done. We are not using
> it and did not look into the details of it.
>
> In what ways does the versioning break it? maybe we can then work out how
> to extend the schema for that.
>
> rgds
> CB
>
>
>>>> 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.
>>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: J2EEStore problems and ideas
Posted by Colin Britton <cb...@metatomix.com>.
Ashok is now away for a few weeks, so he will not be able to have a look.
Versioning was not included when the new schema was done. We are not using
it and did not look into the details of it.
In what ways does the versioning break it? maybe we can then work out how
to extend the schema for that.
rgds
CB
> >> 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.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: J2EEStore problems and ideas
Posted by Jean-Philippe Courson <co...@noos.fr>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: J2EEStore problems and ideas
Posted by Christopher Lenz <cm...@gmx.de>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>