[rules-users] Guvnor repository database use to store assets

[Nicolas Héron]

Hi,

Sorry, but you do not have to delete the workspace directory. Not sure where
> you are getting this from? In cases where you have a large number of
> packages/assets in Guvnor it is rather recommended _not_ to delete the
> search indexes written onto the file system, because it takes extra time to
> re-create them.
>

May be it is recommended. But when you modify a lot the assets, rename,
copy, delete,etc.. Guvnor gets lost.


>  At startup, Jackrabbit (containent in Guvnor) reads all the database and
> creates the two directories. You do not need to backup them.
>
> Again, I don't know where you are getting this from. Jackrabbit does _not_
> read the entire DB on startup and does not write any of the JCR content
> stored in an RDBMS to the file system if you have configured it to store to
> the RDBMS. If you for any weird reason are seeing this on your end, you
> should really have another look at your repository.xml.
>


The search indexes, they are stored on the file system no ? And with no
index, you cannot reach any of the assets. So when you delete thoses
directories, at startup, they are re-created and the database is read. I do
not know what is read, but it can take quite some times, depending on the
size of the package. Now If there is a way to store thoses indexes in the
database, I would be happy to know how.

The project I am on has many rules and many big web decision tables that end
up with more than 100000 rules.  I am using 5.3 snapshot with MVEL beta6 =>
Startup time =5 minutes and building the package, 3 to 5 minutes on a HP G6
processor. On my PC that has an i5 processor and a 32 bits linux, I cannot
build anymore the package.
With those sizes, which is not that much, Guvnor/jackrabbits gets lots on
the indexes : it gives jackrabbit exceptioorn or spaces are not considered.
So then, what I do is delete those two directories and restart guvnor and
everything is fine again.
Thanks
Nicolas


>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110905/033d63d2/attachment.html