incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <j...@digiverse.si>
Subject Re: [Apache Bloodhound] #288: Create prototype for legacy database schema proxy
Date Mon, 28 Jan 2013 12:08:40 GMT
On 1/25/13 7:05 PM, Apache Bloodhound wrote:
>   > One note though, the permission test should include product column value
>   when inserting into global environment. But you might wait with that till
>   after my patch...
>
>   IMO it's quite important to be consistent with the previous approach (i.e.
>   no explicit reference to products in SQL queries ). All this should be
>   encapsulated e.g. the proxy has to detect whether a product is not set in
>   context and still translate the query considering `product = NULL` (
>   `product = ''` ? ) . All instances of `product = NULL` will refer to
>   resources in the global environment . That would be enough to keep the
>   interface exactly the same as before .
>
>   I don't know how much complicated this will be for you to add this feature
>   , but IMO it's a **MUST** . Is it feasible up to this point ?
>
>   Everything **must** be just like before for both product envs and global
>   env . That's exactly the point .
>   ''';)'''

I don't find 'product detection' code very appealing. Assuming that 
detecting the product column within the INSERT statement would be 
relatively easy to do, detecting WHERE conditions is not that trivial.

Therefor I would suggest the following solution - the code should always 
run within ProductEnvironment (and never global Environment).  In the 
global context (URL namespace), the code should get the 
ProductEnvironment with the `product == ''`, which would reference 
global resources. This would keep the backward compatibility for 3rd 
party plugins/trac code even when running in global context - with the 
database view limited to 'global product'.

The product aware code would, on the other hand, in both cases (global 
and/or product context), have access to global view of the resources 
through env.parent property. The translator code would still be disabled 
when accessing database through env.parent, making it possible for the 
code/plugins to access all product's resources.

Any other takes on this?

Cheers,
Jure




Mime
View raw message