Allow Contract classes to make modifications to operations

[keyboardr]

Allow the Contract classes to specify classes to modify queries, deletes, inserts, and updates.

A primary use case for this would be to allow contract classes to do joins, subselects, group-bys, etc. without modifying the provider subclass (which would normally require copying over the full method).

I'll have a pull request to follow this up, but I wanted to get input on it while I'm working on it. So far my approach is to add a new Modifier annotation and four new interfaces (DeleteModifier, InsertModifier, QueryModifier, and UpdateModifier). Each of the new interfaces would have one method per relevant parameter (table, projection, selection, values, etc), and would take all of the original values as parameters. Contract uses instanceof in its constructor to determine which type of modifier is referenced by the annotation. ProviGenProvider then uses the modifiers when performing the relevant method.

[TimotheeJeannin]

Hi @keyboardr

I have the feeling that a fair of amount of users might need to modify the behavior of queries, deletes, inserts and updates. And ProviGen doesn't provide an easy documented way to do it. As you said the user needs to understand how ProviGen works and needs to copy over the full query / delete / insert /update methods to achieve this. So, we probably should do something about it.

Now, I don't know what's the best approach. On the first hand if we add a new Modifier annotation and new interfaces, I have the feeling that the user will need to understand where to put the annotation, what the annotations are doing, what are the implication on the queries etc. And I feel like it's might be a kind a usable 'black box', but that doesn't really put the user in control. If they want a specific behavior in the first place, maybe we should let them write a specific implementation. On the other hand if we don't modify ProviGen and just add documentation about "how to do it" it might be a bit cumbersome to copy over full methods.

I think we need to think about this a little bit more and consider all the options we have. What do you think ?

[keyboardr]

I've used ProviGen on several projects, and it's gotten to the point that I
pull in the source even if I think my Provider will be simple. The nice
thing about the Modifier approach is that it's 100% transparent to those
who aren't using it while providing enough flexibility for the advanced
users who are. My biggest concern is that I've only used this approach on
one project, although it seems it would accomplish the goals of other
projects I've had. I'll get my version up on GitHub so you can at least see
it, but so far it's just a rough draft.

On Wed, Sep 10, 2014 at 12:37 AM, Timothée Jeannin <[email protected]

wrote:

Hi @keyboardr https://github.com/keyboardr

I have the feeling that a fair of amount of users might need to modify the
behavior of queries, deletes, inserts and updates. And ProviGen doesn't
provide an easy documented way to do it. As you said the user needs to
understand how ProviGen works and needs to copy over the full query /
delete / insert /update methods to achieve this. So, we probably should do
something about it.

Now, I don't know what's the best approach. On the first hand if we add a
new Modifier annotation and new interfaces, I have the feeling that the
user will need to understand where to put the annotation, what the
annotations are doing, what are the implication on the queries etc. And I
feel like it's might be a kind a usable 'black box', but that doesn't
really put the user in control. If they want a specific behavior in the
first place, maybe we should let them write the a specific implementation.
On the other hand if we don't modify ProviGen and just add documentation
about "how to do it" it might be a bit cumbersome to copy over full
methods.

What do you think ?

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

[keyboardr]

There's some whitespace and formatting issues, as well as some minor code
cleanliness issues, but the core concept is here:
keyboardr@fc6478f

On Wed, Sep 10, 2014 at 4:35 AM, Josh Brown [email protected] wrote:

I've used ProviGen on several projects, and it's gotten to the point that
I pull in the source even if I think my Provider will be simple. The nice
thing about the Modifier approach is that it's 100% transparent to those
who aren't using it while providing enough flexibility for the advanced
users who are. My biggest concern is that I've only used this approach on
one project, although it seems it would accomplish the goals of other
projects I've had. I'll get my version up on GitHub so you can at least see
it, but so far it's just a rough draft.

On Wed, Sep 10, 2014 at 12:37 AM, Timothée Jeannin <
[email protected]> wrote:

Hi @keyboardr https://github.com/keyboardr

I have the feeling that a fair of amount of users might need to modify
the behavior of queries, deletes, inserts and updates. And ProviGen doesn't
provide an easy documented way to do it. As you said the user needs to
understand how ProviGen works and needs to copy over the full query /
delete / insert /update methods to achieve this. So, we probably should do
something about it.

Now, I don't know what's the best approach. On the first hand if we add a
new Modifier annotation and new interfaces, I have the feeling that the
user will need to understand where to put the annotation, what the
annotations are doing, what are the implication on the queries etc. And I
feel like it's might be a kind a usable 'black box', but that doesn't
really put the user in control. If they want a specific behavior in the
first place, maybe we should let them write the a specific implementation.
On the other hand if we don't modify ProviGen and just add documentation
about "how to do it" it might be a bit cumbersome to copy over full
methods.

What do you think ?

—
Reply to this email directly or view it on GitHub
#33 (comment)
.