Camel
  1. Camel
  2. CAMEL-4300

camel-cache - Make it possible to specify cache operation / key in endpoint uri

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.8.0
    • Fix Version/s: 2.10.0
    • Component/s: camel-cache
    • Labels:
      None
    • Estimated Complexity:
      Novice

      Description

      Currently you need to provide headers with an operation and key. Instead it should be simpler to do in the uri directly

      .to("cache:myCache?operation=update&key=foo");

      But if there is any headers, then they should take precedence. This is the normal convention with other Camel components. That headers takes precedence over uri configuration.

      1. camelCacheUrlOpts.patch
        15 kB
        Piotr Klimczak
      2. camel-cache.uri-config-imp.patch
        17 kB
        Piotr Klimczak

        Activity

        Hide
        Piotr Klimczak added a comment -

        Hi Claus!
        I will give it a try. I will start developing in next two weeks. Is that ok?

        Show
        Piotr Klimczak added a comment - Hi Claus! I will give it a try. I will start developing in next two weeks. Is that ok?
        Hide
        Claus Ibsen added a comment -

        Piotr, that is great.

        Show
        Claus Ibsen added a comment - Piotr, that is great.
        Hide
        Ioannis Canellos added a comment -

        Piotr, what is the status about it? Need any help with it?

        Show
        Ioannis Canellos added a comment - Piotr, what is the status about it? Need any help with it?
        Hide
        Piotr Klimczak added a comment -

        Sorry for leaving this improvement w/o answer.
        Unfortunately I did not have a chance to start programming yet. This is because I became a happy father much earlier than I thought (few weeks) and because of that I am doing much repairs in my flat.

        This is also the very first moment when i have turned on my PC since last few weeks.
        For now I am not sure when I will be able to start programming (maybe at the beginning of October).

        Please don't get me wrong- I do really want to make this improvement as since my last changes I feel a kind of "owner" of cache component. But I'm not free enough to do it now.

        Hope you don't mind.

        Show
        Piotr Klimczak added a comment - Sorry for leaving this improvement w/o answer. Unfortunately I did not have a chance to start programming yet. This is because I became a happy father much earlier than I thought (few weeks) and because of that I am doing much repairs in my flat. This is also the very first moment when i have turned on my PC since last few weeks. For now I am not sure when I will be able to start programming (maybe at the beginning of October). Please don't get me wrong- I do really want to make this improvement as since my last changes I feel a kind of "owner" of cache component. But I'm not free enough to do it now. Hope you don't mind.
        Hide
        Piotr Klimczak added a comment -

        Does anybody know, when camel 2.9 is going to be released?
        Is there anybody who is working with this improvement?
        I'm asking because it possible that I will be able to make it next week.

        If i will not receive any answer until Friday, i will probably start coding at Friday night.

        Show
        Piotr Klimczak added a comment - Does anybody know, when camel 2.9 is going to be released? Is there anybody who is working with this improvement? I'm asking because it possible that I will be able to make it next week. If i will not receive any answer until Friday, i will probably start coding at Friday night.
        Hide
        Claus Ibsen added a comment -

        Nobody is working on this. Looking forward to your help.

        Show
        Claus Ibsen added a comment - Nobody is working on this. Looking forward to your help.
        Hide
        Piotr Klimczak added a comment - - edited

        I am thinking about usability of this improvement.
        In your example i can see that the key param is static. It makes it quite unusable.

        So i have decided to use simple language which will make it much more powerfull.

        So basic example looks like this: to("cache://TestCache1?operation=add&key=$

        {body.id}

        ").
        Nice isn't it?

        As i know the url parameters incjection functionality doesn't support "dynamic" values (can inject only static string). So the simple language functionality can be added with very small additional code with BaseSimpleParser.

        Please tell me what do you think about this Claus? Is that ok to use a simple language in URLS? Or maybe it will break some compatybility with spring/blueprint or any other thing?

        Waiting for your answer.

        Show
        Piotr Klimczak added a comment - - edited I am thinking about usability of this improvement. In your example i can see that the key param is static. It makes it quite unusable. So i have decided to use simple language which will make it much more powerfull. So basic example looks like this: to("cache://TestCache1?operation=add&key=$ {body.id} "). Nice isn't it? As i know the url parameters incjection functionality doesn't support "dynamic" values (can inject only static string). So the simple language functionality can be added with very small additional code with BaseSimpleParser. Please tell me what do you think about this Claus? Is that ok to use a simple language in URLS? Or maybe it will break some compatybility with spring/blueprint or any other thing? Waiting for your answer.
        Hide
        Piotr Klimczak added a comment -

        Done!

        Please take a look. As i said i have added the Simple language goodnes support for operation and key parameters.

        Have a FUN

        Show
        Piotr Klimczak added a comment - Done! Please take a look. As i said i have added the Simple language goodnes support for operation and key parameters. Have a FUN
        Hide
        Claus Ibsen added a comment -

        The other components dont use simple language in the key name. I think we should make it consistent. And I cannot see a use case where you want this.

        Show
        Claus Ibsen added a comment - The other components dont use simple language in the key name. I think we should make it consistent. And I cannot see a use case where you want this.
        Hide
        Piotr Klimczak added a comment -

        Let`s talk about usability.
        For better understanding please take a look at below example:

        RouteBuilder builder = new RouteBuilder() { public void configure()

        { from("direct:start") .setHeader(CacheConstants.CACHE_OPERATION, constant(CacheConstants.CACHE_OPERATION_ADD)) .setHeader(CacheConstants.CACHE_KEY, constant("Ralph_Waldo_Emerson")) .to("cache://TestCache1") }

        };

        In this example the cache key is static. It means that every message will be added to the cache with same key. In other words there will always be only one thing in the cache- the last added message.

        Believe me you do not want this.
        In my opinion this situation will cause any cache absolutely unusable.

        I am using this component for some time and every each time i am using it altogether with simple language

        Show
        Piotr Klimczak added a comment - Let`s talk about usability. For better understanding please take a look at below example: RouteBuilder builder = new RouteBuilder() { public void configure() { from("direct:start") .setHeader(CacheConstants.CACHE_OPERATION, constant(CacheConstants.CACHE_OPERATION_ADD)) .setHeader(CacheConstants.CACHE_KEY, constant("Ralph_Waldo_Emerson")) .to("cache://TestCache1") } }; In this example the cache key is static. It means that every message will be added to the cache with same key. In other words there will always be only one thing in the cache- the last added message. Believe me you do not want this. In my opinion this situation will cause any cache absolutely unusable. I am using this component for some time and every each time i am using it altogether with simple language
        Hide
        Piotr Klimczak added a comment -

        sorry for multiple comments i am using my tablet.

        So the usual usage of camel cache component is:
        RouteBuilder builder = new RouteBuilder() { public void configure()

        { from("direct:start") .setHeader(CacheConstants.CACHE_OPERATION, constant(CacheConstants.CACHE_OPERATION_ADD)) .setHeader(CacheConstants.CACHE_KEY, simple("body.id")) .to("cache://TestCache1") }

        };

        This is equal to: to("cache://TestCache1? operation=add&key=$

        {body.id}

        ").

        I just cannot imagine usability of this component w/o simple language or any other, as the CA he key must be dynamic and is always in body or set as a header of message.

        Please let me know if i made you to change your mind.

        Greetings,
        Piotr Klimczak

        Show
        Piotr Klimczak added a comment - sorry for multiple comments i am using my tablet. So the usual usage of camel cache component is: RouteBuilder builder = new RouteBuilder() { public void configure() { from("direct:start") .setHeader(CacheConstants.CACHE_OPERATION, constant(CacheConstants.CACHE_OPERATION_ADD)) .setHeader(CacheConstants.CACHE_KEY, simple("body.id")) .to("cache://TestCache1") } }; This is equal to: to("cache://TestCache1? operation=add&key=$ {body.id} "). I just cannot imagine usability of this component w/o simple language or any other, as the CA he key must be dynamic and is always in body or set as a header of message. Please let me know if i made you to change your mind. Greetings, Piotr Klimczak
        Hide
        Bilgin Ibryam added a comment -

        Hi Piotr,

        a late congrats on becoming father

        I agree with you that using the same key for the cache doesn't make much sense, but consistency among all these components is also important. By specifying statically the operation and the key in the URI you actually specify only the default values, and you can always override them using the message header. For example in the URI you could specify only the operation, and use message header for the key only if it is needed.

        Show
        Bilgin Ibryam added a comment - Hi Piotr, a late congrats on becoming father I agree with you that using the same key for the cache doesn't make much sense, but consistency among all these components is also important. By specifying statically the operation and the key in the URI you actually specify only the default values, and you can always override them using the message header. For example in the URI you could specify only the operation, and use message header for the key only if it is needed.
        Hide
        Piotr Klimczak added a comment -

        Sorry for late answer.
        I do understad both of you. So few weeks ago i have decided to abandon this improvement havng another idea on my mind.
        So as we all are right and we should take care about consistency and functionality- both together.
        The solution to meet our needs should be something like:
        CacheDefinition c = From("seda:in").cache( CacheConstants.CACHE_OPERATION_ADD, simple("in.body"));
        This proposition takes careabout consistency.

        If you think it is a better idea, then i will prepre full proposition of imrovement.
        For now as cache component is bit difficult to use, we should make it much easier to people. In my opinion my lst proposition is fulfilling all needs.

        WDYT?

        Show
        Piotr Klimczak added a comment - Sorry for late answer. I do understad both of you. So few weeks ago i have decided to abandon this improvement havng another idea on my mind. So as we all are right and we should take care about consistency and functionality- both together. The solution to meet our needs should be something like: CacheDefinition c = From("seda:in").cache( CacheConstants.CACHE_OPERATION_ADD, simple("in.body")); This proposition takes careabout consistency. If you think it is a better idea, then i will prepre full proposition of imrovement. For now as cache component is bit difficult to use, we should make it much easier to people. In my opinion my lst proposition is fulfilling all needs. WDYT?
        Hide
        Piotr Klimczak added a comment -

        please note that i do not like the setHeader way, neither the when(header()) way.
        It makes the code muchmore complicated than it should. Such simple things like checking was the cache found or not should be done w/o heders.
        Right now i am not sure how, but in my opinion using headers should be an option instead of beingthe only way.
        I am considering something like
        .cacheGet(simple("in.body"), true).
        whenNotFound().to("seda:prepareValue").end().to("seda:destination");

        The second parameter of cacheGet is a flag where true means that the cache will be automatically added when the "whenNotFound" block is finished, bu sure is it possible right now. It is just an idea.
        But more/less this is how camel-cache of my dreams looks like.

        Greetings
        Piotr

        Show
        Piotr Klimczak added a comment - please note that i do not like the setHeader way, neither the when(header()) way. It makes the code muchmore complicated than it should. Such simple things like checking was the cache found or not should be done w/o heders. Right now i am not sure how, but in my opinion using headers should be an option instead of beingthe only way. I am considering something like .cacheGet(simple("in.body"), true). whenNotFound().to("seda:prepareValue").end().to("seda:destination"); The second parameter of cacheGet is a flag where true means that the cache will be automatically added when the "whenNotFound" block is finished, bu sure is it possible right now. It is just an idea. But more/less this is how camel-cache of my dreams looks like. Greetings Piotr
        Hide
        Piotr Klimczak added a comment -

        W/O simple language

        Show
        Piotr Klimczak added a comment - W/O simple language
        Hide
        Claus Ibsen added a comment -

        Thanks for the patch. I updated the cache wiki page with the 2 new endpoint options.

        Show
        Claus Ibsen added a comment - Thanks for the patch. I updated the cache wiki page with the 2 new endpoint options.

          People

          • Assignee:
            Claus Ibsen
            Reporter:
            Claus Ibsen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development