gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Madhawa Kasun Gunasekara <madhaw...@gmail.com>
Subject Re: Redis datastore
Date Mon, 03 Jun 2019 09:07:39 GMT
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.


On Mon, May 27, 2019 at 9:17 AM Kevin Ratnasekera <djkevincr1989@gmail.com>

> Hi Xavier,
> Please find my answers inline.
> On Mon, May 27, 2019 at 10:33 AM FRANCISCO XAVIER SUMBA TORAL
> <xavier.sumba93@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.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message