PostgreSQL: How to handle table and view dependencies

PostgreSQL is very restrictive when it comes to modyfing existing objects. Very often when you try to ALTER TABLE or REPLACE VIEW it tells you that you cannot do it, because there's another object (typically a view or materialized view), which depends on the one you want to modify. It seems that the only solution is to DROP dependent objects, make desired changes to the target object and then recreate dropped objects.


DB view dependencies in PostgreSQL


I recently learned a clever trick in PostgreSQL, which allows you to check which DB views and tables are used by any view. It allows you to see view's dependency tree, for example:
public.v_top_department depends on public.v_department_sales_per_employee
  public.v_department_sales_per_employee depends on public.v_department_sales
    public.v_department_sales depends on public.departments
    public.v_department_sales depends on public.sales
  public.v_department_sales_per_employee depends on public.v_department_employees
    public.v_department_employees depends on public.departments
    public.v_department_employees depends on public.employees


Spring Security: authorization on controller methods, part 2

In my previous post I showed a method to apply authorization rules to controller methods using annotations without moving <global-method-security> or @EnableGlobalMethodSecurity to web application context. My solution was something between web security and global method security. It operated on HTTP request level (just like web security), but it was configured by annotations (like global method security).

I improved my code from previous post, so it integrates with Spring Security better, and I packaged it as a library (spring-security-controller-auth). In this post I would like to describe this library.


Spring Security: authorization on controller methods

Spring Security offers three methods of authorization:
  • securing URLs using <intercept-url> or authorizeRequests() in XML/Java config (also called web security or URL security)
  • securing individual method invocations using <global-method-security> or @EnableGlobalMethodSecurity
  • securing domain objects using ACL
The first method is well-suited for securing servlets and controllers.
The second works (with a default configuration) for service layer components, but not for controllers. This is because you usually add Spring Security in root application context and, since controllers live in web application context, Spring Security cannot access them. Still, very often developers try to apply global method security to controller methods. Spring Security FAQ has even an answer to such question. Usually the solution is to move <global-method-security> to web application context.

I think that many of those developers actually don't need global method security on controller methods. For example see these four threads: [1], [2], [3] and [4] - they all require a simple "hasRole(XXX)" check. So I think that what they really need is to configure some authorization mechanism using annotations directly on controller methods (because it is more convenient than configuring it using URL patterns). It doesn't matter, if it's web security or global method security. However, they choose global method security, because it supports annotations.

In this post I would like to show an alternative approach - something that is between web security and global method security. It will use web security expressions, but will be configured by annotations applied to controller methods. Let's see how this can be implemented.


How to create custom form property types in Activiti

Activiti BPM engine provides support for creating forms for user tasks. Out-of-the box the following form property types are supported: string, long, enum, date, boolean. In this post I would like to show you, how you can add custom form property type.


Handling exceptions with Guava

Some time ago, while reading Java Concurrency In Practice, I encountered the following utility method:
public static RuntimeException launderThrowable(Throwable t) {
  if (t instanceof RuntimeException)
    return (RuntimeException) t;
  else if (t instanceof Error)
    throw (Error) t;
    throw new IllegalStateException("Not unchecked", t);
At first it looks quite strange, so let's see how it can be used.


Yet another guide to Spring Data JPA

I've been learning Spring Data JPA recently and I am really impressed by its features and ease of use. It allows to create JPA based data access layer very quickly. In a basic usage scenario you only need to create interfaces which extend specific Spring interfaces and which have methods named according to appropriate convention - and that's it. Spring Data JPA will automatically provide implementations of those interfaces.

I created a simple project, which demonstrates basic features of Spring Data JPA. The source code can be downloaded here and the most interesting parts are described below.