Hello, About trying other libraries, it is a broad task. There are a lot and each of them has its own advantage/disadvantage. Redisson, looks promising and think we can use that one instead of Jedis, but I am still comparing with other libraries. I will get back with this comparison soon.
After looking into Gora’s source code, the datastores have a different paradigm than Redis for storing data. So, I am still finding a way to map gore’s fields with avro and key registers from redis. This goes hand in hand with the selection of the library. About testings basic operations and a single node is necessary. There is a comment of Kevin below, but I will look into Aerospike to analyze if there a more suitable option. I will work in the mapping from gora <-> redis. Best, Xavier > On Jun 4, 2019, at 17:04, carlos muñoz <carlosr...@gmail.com> wrote: > > > Hi Xavier. > > Please note that redis-mock has some limitations. > Alternatively, If you realize that you need unsupported operations you can > use docker, give a look to the Aerospike tests [2]. > > my two cents, > > [1] https://github.com/fppt/jedis-mock#supported-operations > <https://github.com/fppt/jedis-mock#supported-operations> > [2] > https://github.com/apache/gora/blob/master/gora-aerospike/src/test/java/org/apache/gora/aerospike/GoraAerospikeTestDriver.java > > <https://github.com/apache/gora/blob/master/gora-aerospike/src/test/java/org/apache/gora/aerospike/GoraAerospikeTestDriver.java> > > Best regards. > Carlos > > El lun., 3 jun. 2019 a las 4:08, Madhawa Kasun Gunasekara > (<madhaw...@gmail.com <mailto:madhaw...@gmail.com>>) escribió: > Hi Xavier, > > It's better to do an analysis of Redis clients. then based on the results, > we can choose what is the appropriate library for the implementation. > Please update this mail thread weekly about your project progress. Mainly > you can update what you have done for the week and what you are hoping to > do in the upcoming week, the problems you face., etc. > > However, I checked your weekly report in the wiki, In that one also, Please > add a section for Next week plan as well. and Please replace "semana" > Spanish word with the appropriate English word. > Please try to update this email thread at least twice a week. Let us know > If you have any questions on the project. > > Thanks, > Madhawa > > > On Mon, May 27, 2019 at 9:17 AM Kevin Ratnasekera <djkevincr1...@gmail.com > <mailto:djkevincr1...@gmail.com>> > wrote: > > > Hi Xavier, > > > > Please find my answers inline. > > > > On Mon, May 27, 2019 at 10:33 AM FRANCISCO XAVIER SUMBA TORAL > > <xavier.sumb...@ucuenca.edu <mailto:xavier.sumb...@ucuenca.edu>.ec.invalid> > > wrote: > > > > > Hello, > > > > > > I am using Jedis Mock [1] to embed Redis for tests. However, I am > > > wondering since redis accepts master/slave cluster / replication / no > > > replication / single instance. Are all those modes necessary? If so, I > > > propose to include them in the gore.properties, but what is the priority > > > given? > > > > > For testing purposes ( mainly in unit tests ), I think it s sufficient to > > run single node cluster. 'gore.properties' should only involve > > configurations that you do when you create a Redis client instance and > > operations you do on top of this client. 'gore.properties' should not > > involve any server side configurations or cluster modes on Server Side. > > However if the Redis client has configurations which directly effects > > cluster modes etc, then you should add them to 'gore.properties'. Basically > > the argument is client you create in datastore should be able to talk to > > server running in both standalone or distributed mode as specified in > > 'gore.properties'. ( You should not hardcode these in client side ) It s > > sufficient run all the tests in standalone mode. By default you may set it > > to standalone mode, if a user required he may have the option to change. > > > > > > > > Additionally, redis support complex datatypes such as lists or sets. > > > However, I think all those datatypes can be handled as Strings, but I > > > wanted to consult what others think. > > > > > As I have mentioned to you earlier with primitive Redis data types, Please > > check whether there are high level libraries available as extensions to > > these Redis types. AVRO has other complex types Eg:- Map, Array, Union, > > Enum etc. See how you can map from/to AVRO from/to Redis. This is part of > > your research. I am also suggesting you to have look on Redisson [1] [2] > > which has AVRO integration. See whether you find anything usable in > > implementation. This also comes as Apache Licensed. Please do a comparison > > of all Redis java client libraries [3] see which suits our needs the most. > > > > [1] https://github.com/redisson/redisson > > <https://github.com/redisson/redisson> > > [2] https://redisson.org/ <https://redisson.org/> > > [3] https://redis.io/clients#java <https://redis.io/clients#java> > > > > Regards > > Kevin > > > > > > > > Best, > > > Xavier. > > > > > > > > > > > > [1] https://github.com/fppt/jedis-mock > > > <https://github.com/fppt/jedis-mock> < > > https://github.com/fppt/jedis-mock <https://github.com/fppt/jedis-mock> > > > > > > > -- > > > Advertencia legal: > > > Este mensaje y, en su caso, los archivos anexos son > > > confidenciales, especialmente en lo que respecta a los datos personales, > > y > > > se dirigen exclusivamente al destinatario referenciado. Si usted no lo es > > > y > > > lo ha recibido por error o tiene conocimiento del mismo por cualquier > > > motivo, le rogamos que nos lo comunique por este medio y proceda a > > > destruirlo o borrarlo, y que en todo caso se abstenga de utilizar, > > > reproducir, alterar, archivar o comunicar a terceros el presente mensaje > > y > > > ficheros anexos, todo ello bajo pena de incurrir en responsabilidades > > > legales. Las opiniones contenidas en este mensaje y en los archivos > > > adjuntos, pertenecen exclusivamente a su remitente y no representan la > > > opinión de la Universidad de Cuenca salvo que se diga expresamente y el > > > remitente esté autorizado para ello. El emisor no garantiza la > > integridad, > > > rapidez o seguridad del presente correo, ni se responsabiliza de posibles > > > perjuicios derivados de la captura, incorporaciones de virus o > > > cualesquiera > > > otras manipulaciones efectuadas por terceros. > > > > > -- Advertencia legal: Este mensaje y, en su caso, los archivos anexos son confidenciales, especialmente en lo que respecta a los datos personales, y se dirigen exclusivamente al destinatario referenciado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo, y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. Las opiniones contenidas en este mensaje y en los archivos adjuntos, pertenecen exclusivamente a su remitente y no representan la opinión de la Universidad de Cuenca salvo que se diga expresamente y el remitente esté autorizado para ello. El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros.
