JOhm to support long id's in line with the update to Jedis incr() about johm HOT 5 CLOSED

done. pushed to master

from johm.

I think, this is not the right way to solve id problem. We need more generic approach to support different id types such as String. At least because redis is key-value store.

from johm.

Anton - a String id is not a very efficient mechanism for anything. At some level, it will have to be transformed to an integer like what Redis does by converting to 64-bit signed int. Actually, if we forget about Redis and focus on our clients, can you give an example where a JOhm client will be better served by having an id String like "94588" instead of just a long/integer type? Apart from String's slowness, we are opening us up to potential number format exceptions. With that tradeoff in mind, unless there is a compelling case where a client will be using String id's (example?), I have never been convinced we should go down that route.

from johm.

My minor goal is go possibly close to JPA specification. This allow easier to migrate from RDBMS.

I don't know how Redis and clients work - it's not my domain. If you say it's bad idea, then it's bad idea :)

Specially in my use case I store user session in Redis (I see Redis/Memcached storages for jetty and tomcat, but not for both containers) and for use JOhm I must generate Long session id's and result is:

UserSessionModel:1215265415737719425

Another cases: coupons and short-url-services, or generally string to whatever mappings.

I can imagine user defined functions to generate id's - this allow generate not only sequential id's as with incr(), ex.:

@model(generator=MyIdGenerator.class)
class MyModel() [...]

class MyIdGenerator {
public static Object generateId(Class entity) {
SecureRandom sr = new SecureRandom().nextLong();
Long id;
do {
id = sr.nextLong();
while ( JOhm.exists(entity, id) );
return id;
}

Sorry, if it's nonsense :)

from johm.

I see what you are saying and this is good thinking and a real-world use-case. So, what you are suggesting is a pluggable IdGenerator option which I like as an idea. I was confused by your earlier suggestion of the string id type: "different id types such as String".

So, now we need to think about global uniqueness in the presence of multiple clients generating id's using the custom IdGenerators and then having to persist to Redis objects loaded with these id's. You could have 15 nodes with JOhm deployments for application persistence all writing to a Redis backing instance and in-memory IdGenerators with potential id conflicts - you get the point.

That brings us back to the search for a reliable globally unique IdGenerator-as-a-service (something like Twitter's specialized service Snowflake). Or a poor man's db-sequence or incr() function :-)

Single-node IdGeneration is relatively trivial but I would love to hear your thoughts on a cheap way (think cross-node IO) to produce global id's. And plugging into JOhm is not a problem - we can easily inject a remote IdGenerationServiceProxy into JOhm and even batch-fetch like 1000 id's and cache client-side for quick-use. Maybe we can keep it simple and just 'extend' the data retrieved by an incr() call by adding some alphanumeric fields to elongate the id.

from johm.