Feature: Support Non Orient Based Repositories - Potentially Extract Repository Framework into Separate Project

[nkoterba]

Ok, so we really like how this project uses Guice AOP and https://github.com/xvik/guice-ext-annotations to create "Repositories" for data. Specifically, we like how the @Delegate can be used to define our DAOs using interfaces and then assign their method execution to base implementation classes.

We have been looking for such a capability and have come across:
Warp-persist: https://code.google.com/p/warp-persist/
Guice-repository: https://code.google.com/p/guice-repository/

Unfortunately, both of these projects are still hosted on Google Code and appear quite outdated.

In addition to using Orient, we are also using Postgres with Hibernate/JPA. We'd really like to use your "repository" Pattern implementation, but there are a few things:

1. We don't want all the other Orient overhead stuff in projects where we are not also using Orient.
2. When we tried to "extend" the existing guice-persist-orient library, the limited DbType enum would not allow us to set a new DbType such as SQL or JPA, which we would need to register our own RepositoryExtensions.

Any interest in extracting out the entire repository framework into its own project?

I've started such an implementation using your code as inspiration but you've already developed and architected so many excellent pieces it seems somewhat silly to do so much.

[xvik]

guice-persist-orient targets orient only so its not the best idea to add jpa support into it directly.
I wrote orient lib because Im tired of hibernate-spring world and want guice-orient freedom. Repositories was grown from guice-persist jpa proxies (not documented on guice wiki, but its the staff from warp-persist).

Repositories mechanism is indeed pretty generic and I could extract it into separate library (all extensions support staff).
After that it would be possible to write new jpa specific extensions for query and other annotations. Delegate extension most likely will be in the core because its not tied to orient.

If this is a good plan for you I will need a week or two for extraction. You will be able to develop your staff using snpashots from jitpack (see project readme snapshots section for example) in parallel.
You can write me directly by mail (see it in my profile).

[nkoterba]

@xvik If you have the ability to separate out repositories and delegation, we would be very appreciate!!!

After looking through all the code, I was thinking of the following:

• So you developed https://github.com/xvik/guice-ext-annotations and this supports AOP method "implementation".
• In this project, you use that coupled with the @Delegate framework to implement an interface by delegating a base class.

I think that "capability" could stand completely on its own without any Repository or DB stuff. I think @Delegate or maybe a new annotation @DelegateTo would be a great addition to https://github.com/xvik/guice-ext-annotations.

Then, there's the Generic Repository framework, which I think could continue to leverage https://github.com/xvik/guice-ext-annotations (as well as the @DeleGate) but provide support for @repository or @RepositoryMethod, etc.

I guess why I see this nice separation is we could also use:

@ProvidedBy(DynamicSingletonProvider.class)
@Delegate(ClassThatWillServeAsDelegate.class)
public interface RestEndpointBase<T> {
  <T> get();
  void post(T newObject);
  void put(T update);
  void delete(T objectToDelete);
}

If @Delegate was not tied to Repository, it could be used anywhere in the code base where you may want to implement an "interface", like REST endpoints. How many REST endpoints all look the same? You have GET, POST, PUT, UPDATE. Would be nice to use this same strategy/pattern in places like that as well.

Thoughts?

[xvik]

I agree that @DeleGate is db agnostic, but it cant be moved to guice-ext-annotations.

Any repository method call is expensive for the first time: there are a lot of analysis and reflection. Thats why after first call composed descriptor object is cached: we do all possible analysys to make future calls as lightweight as possible.
Delegate is not an exception, so it would have to stay in repository core module (need the same infrostructure).

After all, core will be a base for orient and jpa moduels (specific extensions), will contain delegate and could also be used to do any db agnistic things like delegates.

Now the bad part: its a huge change and, what is worse, its breaking change for guice-persist-orient (at least annotation packages will change).
There are few tasks that must be done before extraction:

1. Orient 2.1 migration (ongoing)
2. Multiple db support (this is actually evolution for guice-ext-annotations to resolve problem with child injectors (issue Failed to initialize scheme #7 ))

Most likely, it would be ready near the end of september (will try to do earlier, but cant promise - dont have a lot of time right now).
Tell me please if you will found other general use cases, or will have other ideas.