There is a slightly tricky point here - if you deny an operations, then
partial operation get done. That's OK on a transactional system - it
simply aborts - but not if it isn't transaction storage. It might be
better to asses the update before dispatching it to the execution engine.
That can be done with Rob's suggestion - do the whole of the request
before any execution.
Andy
On 29/10/12 18:02, Rob Vesse wrote:
Re Step 2 - I just made a commit to trunk so that with the latest code you
can extend UpdateEngineMain and simply override the protected
prepareWorker() method to return your custom UpdateVisitor rather than the
default UpdateEngineWorker I.e. this avoids the need to implement the
execute() method yourself
Also in Step 3 you should be extending from UpdateEngineWorker rather than
the non-existent UpdateWorker
Hope this helps,
Rob
On 10/29/12 9:53 AM, "Rob Vesse" <[email protected]> wrote:
Hey Dick
Yes we do this in our product in a production environment to replace the
standard update handling with our own completely custom one
Your desired extension is actually even easier than ours, extending Update
evaluation basically requires you to do three things as follows.
1 - Create and register a custom UpdateEngineFactory
Create a class that implements the UpdateEngineFactory interface, this has
two methods for you to implement. Simply return true for the accept()
method to indicate you wish to handle all updates and then for the
create() method return a new instance of the class you create in Step 2
Your code will need to ensure that this factory gets registered by calling
UpdateEngineRegistry.add(new CustomUpdateEngineFactory()); in order for
your code to intercept updates.
2 - Create a custom UpdateEngine
Create a class that extends from UpdateEngineBase and implements the
abstract execute() method, you can simply modify the default
implementation found in UpdateEngineMain like so:
@Override
public void execute()
{
graphStore.startRequest(request) ;
CustomUpdateEngineWorker worker = new
CustomUpdateEngineWorker(graphStore, startBinding, context) ;
for ( Update up : request ) {
up.visit(worker) ;
}
graphStore.finishRequest(request) ;
}
3 - Create your custom UpdateVisitor
Create a class that extends from UpdateWorker, this is the class you are
referencing as CustomUpdateEngineWorker from Step 2, I assume you pick a
more appropriate name. Then you simply override the methods that you want
to add access control functionality to like so:
@Override
public void visit(UpdateCreate update)
{
if (deny(args)) {
//Handle the error case
} else {
//Otherwise defer to normal logic
super.visit(update);
}
}
Hope this helps,
Rob
On 10/29/12 6:43 AM, "Dick Murray" <[email protected]> wrote:
Hi all
I need to permit/deny certain SPARUL update operations e.g. deny create|
drop graph.
I've looked at the UpdateEngineMain and UpdateVisitor classes and was
wondering if anyone has extended or encapsulated these before? Ideally
I'd
like to capture the "visit" just prior to the actual visit.
i.e the UpdateEngineWorker has...
@Override
public void visit(UpdateCreate update)
{
Node g = update.getGraph() ;
if ( g == null )
return ;
if ( graphStore.containsGraph(g) )
{
if ( ! alwaysSilent && ! update.isSilent() )
error("Graph store already contains graph : "+g) ;
return ;
}
// In-memory specific
graphStore.addGraph(g, GraphFactory.createDefaultGraph()) ;
}
...and I need a...
if (deny(...)) {
error("update create denied");
return;
Also need it too work whether the graphStore was from a Dataset or TDB...
ideally... :-)
Regards Dick.
