<html><head></head><body bgcolor="#FFFFFF"><div>I dont want to fork or threat, thats the last thing i want. i'm just saying that i dont see any other solution until the fix is in next year.&nbsp;</div><div><br></div><div>md5 hash of the schema is a great idea, at the moment it prints out the whole xml<br><br>paul<br><div><br></div></div><div><br>Am 31.08.2012 um 03:18 schrieb Pedro Alves &lt;<a href="mailto:pedro.alves@webdetails.pt">pedro.alves@webdetails.pt</a>&gt;:<br><br></div><div></div><blockquote type="cite"><div><div><br></div>As long as it works, fine by me.<div><br></div><div><br></div><div>Jpivot is the smallest issue, we can just remove the dynresolver part in pivot.jsp (we're doing it now with that spi anyway).&nbsp;</div><div>
<br></div><div><br></div><div>However, I'm worried about what I can't control.</div><div><br></div><div>Julian, how does that affect:</div><div><br></div><div>- Analyzer</div><div>- prd (cda uses prd libs, mondrian datasources)</div>
<div>- xactions&nbsp;</div><div><br></div>How could we make sure these would pass the correct property?&nbsp;<div><br><div><br></div><div>I'm not sure if all of them fall back to mondrianutils class. Would be simpler if so, though I have no idea if it passes all properties</div>
<div><br></div><div><br></div><div>&nbsp;how can we define that property? I guess I could through context.xml, but not sure if thats the case with all the ways we can define dtasources in pentaho.&nbsp;<br><div><br></div><div><br></div>
<div>And... Maitaining a branch, please, anything but that....<br><br><br><br>On Friday, August 31, 2012, Paul Stoellberger  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think thats a good approach in general. the only issues i see are how the api is used differently within the server:<br>
- jpivot passes a dynamicschemaprocessor, making the schema xml part of the key<br>
- mdxconnection doesnt pass along all parameters defined in darasources.xml<br>
- saiku passes the exact connection details from datasources.xml<br>
<br>
so if there is a jdbcconnectionuuid passed thats not ensuring that the catalog part is the same as well.<br>
<br>
i understand your concern, but i'm not too convinced we can ensure that the same keys are used regardless in which environment mondrian is used.<br>
<br>
and its too bad there wont be a fix before next spring/summer... i guess we will have to maintan a branch ourselves then...<br>
<br>
-paul<br>
<br>
<br>
<br>
<br>
Am 31.08.2012 um 02:29 schrieb Julian Hyde &lt;<a href="javascript:;" onclick="_e(event, 'cvml', 'jhyde@pentaho.com')">jhyde@pentaho.com</a>&gt;:<br>
<br>
&gt; On Aug 27, 2012, at 10:25 AM, Pedro Alves &lt;<a href="javascript:;" onclick="_e(event, 'cvml', 'pedro.alves@webdetails.pt')">pedro.alves@webdetails.pt</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; I know that "mondrian" and "cache" are 2 words that when used together<br>
&gt;&gt; make everyone's eyes roll. We've been talking about it for so long, and<br>
&gt;&gt; it's still an issue.<br>
&gt;&gt;<br>
&gt;&gt; In the end, mondrian users are the ones that mostly suffer about it.<br>
&gt;&gt; Paul and I (I as in the webdetails team that actually does the work, I<br>
&gt;&gt; just write emails) went ahead and "fixed" it by turning the cache key<br>
&gt;&gt; into an SPI:<br>
&gt;&gt;<br>
&gt;&gt; <a href="https://github.com/webdetails/mondrian/compare/master...schemaKey" target="_blank">https://github.com/webdetails/mondrian/compare/master...schemaKey</a><br>
&gt;<br>
&gt;<br>
&gt; As I promised, I talked to the BI Server guys about this.<br>
&gt;<br>
&gt; They are committing to move BI Server to olap4j by Sugar timeframe (currently April 2013 -- and everyone this knows this date will probably move). That will improve a lot of things. It's not as early as we'd all like, but it's a start.<br>

&gt;<br>
&gt; It's important to me that connection factories (the means by which Mondrian gets JDBC connections to the underlying databases... which include instances of javax.sql.DataSource, or (URL, username) credentials) can be represented as strings. It was a mistake to allow javax.sql.DataSource objects to be passed into Mondrian when creating a connection via the legacy API. olap4j made it more difficult to pass in non-Strings, and that made life painful for some people. I thought it would be possible to just register DataSources in JNDI and pass in the JDNI name, but as Marc pointed out, Pentaho has to run in containers (such as Tomcat) with read-only JNDI environments.<br>

&gt;<br>
&gt; Mondrian already has a DataSourceResolver SPI. This is important, and this works. The one thing it doesn't do is tell Mondrian whether two data sources point to the same database.<br>
&gt;<br>
&gt; Consider setting up a distributed cache. It's important that all of the participating instances of Mondrian know that they are looking at the same database instance. If they don't know it's the same database, they can't safely share their cache. If we used an SPI to determine equality, it's difficult to ensure that the same SPI is being used on all machines. When I'm answering a support call, it's easy to forget to ask whether someone has overridden the default implementation of the SPI.<br>

&gt;<br>
&gt; So, how to tell whether two connection factories are the same, without introducing an SPI? We introduce a new connect string parameter, JdbcConnectionUuid. (This complements existing parameters Jdbc, JdbcUser, JdbcPassword and DataSource.) If two mondrian connections have the same JdbcConnectionUuid, Mondrian will take the client at its word that the back-end databases are identical. It will not consider the other parameters in determining equality.<br>

&gt;<br>
&gt; Determining whether two schemas are equal, and therefore candidates for sharing a cache, comes down to two parts: Are the connection factories equal (using JdbcConnectionUuid etc. as described above)? And are the contents of the XML schema files equal (using UseContentChecksum, Catalog, CatalogContent, DynamicSchemaProcessor, as today)? Both of these questions are answered by looking at a string.<br>

&gt;<br>
&gt; JdbcConnectionUuid is optional in the connection parameters. If not specified, Mondrian would use the same connection factory matching rules as today. (Internally, Mondrian will generate a Uuid so that all connections have one.)<br>

&gt;<br>
&gt; As its name suggests, it's a good idea if JdbcConnectionUuid is a UUID. But it doesn't need to be. It could be an MD5 hash. It could be anything the user likes. They should just make damn sure that it is unique.<br>

&gt;<br>
&gt; in conclusion. I am going to reject the SPI you have implemented, even on the master branch (3.4). Sorry! I believe that JdbcConnectionUuid is the right solution, for both short and long term, so let's start using it as soon as possible. If someone implements it as I have described above, I will accept the patch into both master and lagunitas branches.<br>

&gt;<br>
&gt; When we implement <a href="http://jira.pentaho.com/browse/MONDRIAN-1177" target="_blank">http://jira.pentaho.com/browse/MONDRIAN-1177</a>, we will provide a means to define the UUID alongside the connection credentials.<br>

&gt;<br>
&gt; Julian<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Mondrian mailing list<br>
&gt; <a href="javascript:;" onclick="_e(event, 'cvml', 'Mondrian@pentaho.org')">Mondrian@pentaho.org</a><br>
&gt; <a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
</blockquote></div><span></span></div></div>
</div></blockquote></body></html>