Hi Xavier, Thank you for the update. Take your time on the research for selecting the Redis client library, you dont need to compare all Redis clients, take a subset/few looks most promising ( by comparing community, functionality etc ). There are only very few recommended from redis.io. [1] ( Jedis, Lettuce and Redisson ) Let's focus on these 3, about high lever data structures etc. Let s do a comparison once you complete that research work.
As Carlos mentioned, If you do have troubles setting up embedded server, you could always use [1] to spin up Redis server instance from docker image. This is the same approach we have taken on Aerospike and CouchDB datastore tests. That way you can spin up a real instance of Redis server, you wont be having any limitations compared to these mock servers. [1] https://redis.io/clients#java [2] https://www.testcontainers.org/ Regards Kevin On Wed, Jun 5, 2019 at 10:20 AM FRANCISCO XAVIER SUMBA TORAL <xavier.sumb...@ucuenca.edu.ec.invalid> wrote: > 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. >
