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 [2] 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>) 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 > > > 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.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 > > [2] https://redisson.org/ > > [3] https://redis.io/clients#java > > > > Regards > > Kevin > > > > > > > > Best, > > > Xavier. > > > > > > > > > > > > [1] 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. > > > > > >
