1

It appears from the documentation that JReJSON only supports JSON. type queries, if I want to use EXISTS on a document I created with JSON.SET do I need an instance Jedis to test for EXISTS?

Using redis-cli I verified that a document I created with JSON.SET reports 1 when tested with EXISTS. so in theory using 2 different clients should work but I wondered if there was a less clunky way?

Guy Korland
  • 9,139
  • 14
  • 59
  • 106
mikee
  • 335
  • 3
  • 11

1 Answers1

0

JReJSON has a constructor which get a Jedis Pool.

    /**
     * Creates a client using provided Jedis pool
     * 
     * @param jedis bring your own Jedis pool
     */
    public JReJSON(Pool<Jedis> jedis) {
        this.client = jedis;
    }

You can use the same pool for your "standard" Redis calls and to create JReJSON

Guy Korland
  • 9,139
  • 14
  • 59
  • 106
  • Thanks @GuyKorland for your response, this is what I ended up doing, (creating 2 clients from the same pool) as you suggested. I was hoping that JReJSON might have the ability to handle non JSON requests even if it just executed them internally via its own private Jedis client. This is my first time experimenting with redis so please forgive any naive assumptions or newbie questions. – mikee May 19 '19 at 15:10
  • If I instantiate a JReJSON instance using the Jedis pool as shown, how do I return the connection to the pool when I am done with the client (in this case it is a @@RequestScoped instance that is creating the JReJSON instance. (I looked through the java doc and there is no close/dispose method. – mikee May 20 '19 at 17:45
  • https://github.com/xetorthio/jedis/wiki/Getting-started#basic-usage-example – Guy Korland May 20 '19 at 18:08
  • I saw this example, however, I should have explained that in my case, the RequestScoped JReJSON client is being Injected (produced by an ApplicationScoped producer method that controls the pool). The Injecting instance has no visibility to to the pool, and worse when the ApplicationScoped destructor method gets called it can't determine which pool connection was used to construct it. The only way this could work is if the JReJSON class had a getPool method so that when the destructor method gets called, it can obtain the pool and close it. – mikee May 20 '19 at 19:26
  • It's possible of course that the Application scoped instance could keep track of the relationship between the pool and the client, but the increasing complexity is starting to get ugly. – mikee May 20 '19 at 19:34