Database vs file system pentaho solution repository.
How does one configure BI Server PUC and the PAC to use database pentaho solution repository? My database of choice currently is MySQL.
Thanks for your help.
the solutions will always stay in the file-system.
The only thing to move to another database might be the Pentaho-Repository itself (i.e. where the users/roles and permissions are stored)
The Community-Edition comes shipped with a HSQL database in which this repository is stored, so you might want to get rid of this one and move the repository to your
existing MySQL database.
For more information about this topic, see the Wiki: http://wiki.pentaho.com/display/Serv...+Repository+DB
Replication of static files, especially across a number of servers, can be difficult to manage. It really comes down to a tradeoff between managing, monitoring and debugging replication problems vs. the database size and load.
I think I'd probably pick the database approach, and if load became an issue look at putting up some sort of cache layer around the image calls.
Suggestions to store a path in the db are missing the real problem, which is replicating this across multiple machines.
Last edited by stacy_kodani; 08-11-2011 at 06:40 AM.
Gee, I thought I was clear with the question but I guess not. Let me try to refine it.
On page 68 of Roland and Jos' book, Pentaho Solutions, they say that "... for precise control over which users can access which content, the solution repository needs to be in a database."
That is what I am trying to understand in detail. What I am asking about, for starters, is a the difference and implementation (how, why, etc) of a db "pentaho solution" repository versus a file systems "pentaho solution" repository.
I followed the instructions given by Prashant Raju on his blog to set up MySQL as the database and load the data he provides. Looking at the hibernate database that is created it looks like roles and permissions are in the database.
But I still have the pentaho-solutions directory and there is "content" there. I can add content to the file system (the pentaho-solutions directory) -- for example the CDF examples.
I feel like I am missing something obvious. Could it be the BI Server is using BOTH? Who is the boss?
I looked at the link in response #2 and it appears to be dealing with a different issue - changing from say Oracle to MySQL for the pentaho database for hibernate, quartz and the data(?). And I have no idea what response #3 is talking about. I am not replicating any thing across multiple machines.
well, since you already moved the instruction from Prashant, you already DID move the Pentaho repository into the database
Putting the whole "pentaho-solutions" directory into the database will not be possible. Access/Roles/Permissions are assigned from within the database (see "hibuser" database, PRO_FILES, PRO_LISTS_ACL Tables)
So you're done already
OK thanks. This is good for starters. Confirms what I am seeing.
I guess the mention of better performance from a file system pentaho-solutions repository in the book was a bit confusing without any instructions anywhere I can find to make the change. Looking through the book, the online documentation and Prashant's notes I did not see "if you want to use a db pentaho-solutions repository for more granular access but less performance do this, and if you want a file system db pentaho-solutions repository with better performance but less access control do this". Seems the default is db, thanks. That is what I want.
So I am partially there to understanding this. Particularly the defaults on who has access permissions to what. The adventure continues...
Last edited by berkeley; 08-11-2011 at 09:05 AM.
the defaults (i.e. which role can see/do on each newly added repository-object) are defined in the "pentaho.xml" file which is to be found in:
In this XML File you find such entries:
<acl-entry role="Admin" acl="FULL_CONTROL" /> <!-- Admin users get all authorities -->
<!-- CTO gets everything -->
<!-- Dev gets execute/subscribe -->
<acl-entry role="Authenticated" acl="EXECUTE" /> <!-- Authenticated users get execute only -->
Which intialize the basic permissions for certain roles.
Note: These ACLs are applied when resetting the permissions.
On top of that you will have the ability to assign permissions to users/roles to each solution object from within the "PUC" (Pentaho User Console; i.e. the webapplication where you can browse/open your reports)
Wow, this is incredibly helpful. Is there documentation for how this all works? This is the exact kind of stuff I am looking for. Let me look through this file. It appears to be a treasure trove.
I have a note that the "visibility attribute" in the index.xml file in each directory in the pentaho-solutions tree turns on and off the ability to see the folder in the PUC browser window.
One of my missions is to have this work (visible or not-visible) based on "role". So Joe admin sees it all. Suzy the developer only sees the bi-developer folders and sub folders. And Pat the accountant only sees the steel-wheels folders.
well, the "visible" attribute for a whole folder is too much, it would disable the whole solution.
But there is the "normal" way to assign permissions to folders (solutions) and/or reports within the folders.
Please see the attached screenshots, they should say more than 1.000 words
Maybe it is because I am using a different release (I am on 3.6.0). But I cannot get to the Properties popup unless I select a particular item in the Files window below the Browse window. Just selecting a folder in the Browse window does not get me to the Properties. Indeed when go to the top File menu item Properties is greyed out.
The goal is to hide the Steel Wheels folders from some roles and the CDF folders from other roles and have an admin role that can see all folders.
Tags for this Thread