I search a lot over web to get more practical usage of #EnableRedisRepositories, but I did not found any. Even in my Spring Boot + Spring Data Redis example, I removed #EnableRedisRepositories but still I did not understood what difference it make, still I can see data is persisting into DB and retrieving fine.
Can somebody please clarify ?
I went through this annotation, but not every clear..
Annotation to activate Redis repositories. If no base package is configured through either {#link #value()},
{#link #basePackages()} or {#link #basePackageClasses()} it will trigger scanning of the package of annotated class.
It lets Spring scan your packages for repository classes/interfaces and then use Redis as the storage to persist your objects to - instead of a classic relational database.
Spring Data docs tell us:
NoSQL storage systems provide an alternative to classical RDBMS for horizontal scalability and speed. In terms of implementation, key-value stores represent one of the largest (and oldest) members in the NoSQL space.
The Spring Data Redis (SDR) framework makes it easy to write Spring applications that use the Redis key-value store by eliminating the redundant tasks and boilerplate code required for interacting with the store through Spring’s excellent infrastructure support.
Related
I am trying to find implementation of GemFire and I am in search of model which can insert data to GemFire as well. I am getting PDX serialization error using CacheWriter.
There are plenty of example in both the Pivotal GemFire and Spring space.
As you may know, Pivotal GemFire is based on the open source Apache Geode, which has a few How-To articles on the Wiki. There is an article on Geode In 5 Minutes that lead you to a few other places.
With Spring Data GemFire, there are plenty of examples, starting with the Spring GemFire Examples GitHub project.
I also have several other examples in my own GitHub account, such as...
The Contacts Application Reference Implementation (RI). This is the most current, up-to-date set of examples since I use these as a single source of truth for conference talks as well as to showcase the latest developments in GemFire with Spring.
I also have an entire GitHub Repository (spring-gemfire-tests) dedicated to reproducing/understanding customer issues, building prototypes or proof-of-concepts, and so on.
Last, but certainly not least, you can review the SDG test suite, which has many of tests that can be used as examples for putting/getting data to/from GemFire using Spring along with configuring PDX. #2 above is also a good resource for this as well.
If you are looking for something in particular, pertaining to your UC, let use know what you UC is and perhaps we/I can direct you better.
Hope this helps!
-John
I can't find any related frameworks. For example, a hybrid ORM/OHM framework for Hibernate and Jedis (JAVA Framework). Is there some reasons that this kind of framework didn't appear yet?
Check
https://github.com/xetorthio/johm
JOhm is a blazingly fast Object-Hash Mapping library for Java inspired by the awesome Ohm. The JOhm OHM is a modern-day avatar of the old ORM's like Hibernate with the difference being that we are not dealing with an RDBMS here but with a NoSQL rockstar.
JOhm is a library for storing objects in Redis, a persistent key-value
database. JOhm is designed to be minimally-invasive and relies wholly
on reflection aided by annotation hooks for persistence. The
fundamental idea is to allow large existing codebases to easily plug
into Redis without the need to extend framework base classes or
provide excessive configuration metadata.
Durable data storage is available via the Redis Append-only file
(AOF). The default persistence strategy is Snapshotting.
Redis is the one of NoSQL database, and it doesn't support rich features provided by RDBs. (secondary index, grouping, query with multiple conditions, etc.) So naturally wrapping Redis operations with SQL doesn't make sense.
If you just want to have Object Mapper for Redis, spring-data-redis provides Serializer/Deserializer so you can store object to bytes in Redis, and load your data to object from Redis.
We're using Redis but considering Infinispan. Redis supports list, hashset, set, and sorted set, and offers native functions to operate over those structures, but does Infinispan support the same?
I know Infinispan will store any Java object, but Redis offers functions that operate on elements without having to explicitly retrieve them. I was wondering if Infinispan supports the same.
Infinispan does not support this out-of-the-box - there is some support for AtomicHashMaps, although I've heard that there may be issues with those.
The main feature you should be looking for is the DeltaAware interface - this allows you to build such collections, sending just the 'operation' that should be executed on the value.
There were some attempts to do so - check out infinispan-contrib (though I don't have any experience with that).
I come from a web development background and haven't done anything significant in Java in quite some time.
I'm doing a small project, most of which involves some models with relationships and straightforward CRUD operations with those objects.
JPA/EclipseLink seems to suit the problem, but this is the kind of app that has File->Open and File->Save features, i.e. the data will be stored in files by the user, rather than persisting in the database between sessions.
The last time I worked on a project like this, I stored the objects in ArrayList objects, but having worked with MVC frameworks since, that seems a bit primitive. On the other hand, using JPA, opening a file would require loading a whole bunch of objects in the database, just for the convenience of not having to write code to manage the objects.
What's the typical approach for managing model data with Java SE desktop applications?
JPA was specifically build with databases in mind. This means that typically it operates on a big datastore with objects belonging to many different users.
In a file based scenario, quite often files are not that big and all objects in the file belong to the same user and same document. In that case I'd say for a binary format the old Java serialization still works for temporary files.
For longer term or interchangeable formats XML is better suited. Using JAXB (included in the standard Java library) you can marshal and demarshal Java objects to XML using an annotation based approach that on the surface resembles JPA. In fact, I've worked with model objects that have both JPA and JAXB annotations so they can be stored in a Database as well as in an XML file.
If your desktop app however uses files that represents potentially huge datasets for which you need paging and querying, then using JPA might still be the better option. There are various small embedded DBs available for Java, although I don't know how simple it is to let a data source point to a user selected file. Normally a persistence unit in Java is mapped to a fixed data source and you can't yet create persistence units on the fly.
Yet another option would be to use JDO, which is a mapping technology like JPA, but not an ORM. It's much more independent of the backend persistence technology that's being used and indeed maps to files as well.
Sorry that this is not a real answer, but more like some things to take into account, but hope it's helpful in some way.
We run multiple websites which use the same rich functional backend running as a library. The backend is comprised of multiple components with a lot of objects shared between them. Now, we need to separate a stateless rule execution component into a different container for security reasons. It would be great if I could have access to all the backend objects seamlessly in the rules component (rather than defining a new interface and objects/adapters).
I would like to use a RPC mechanism that will seamlessly support passing our java pojos (some of them are hibernate beans) over the wire. Webservices like JAXB, Axis etc. are needing quite a bit of boiler plate and configuration for each object. Whereas those using Java serialization seem straightforward but I am concerned about backward/forward compatibility issues.
We are using Xstream for serializing our objects into persistence store and happy so far. But none of the popular rpc/webservice framework seem use xstream for serialization. Is it ok to use xstream and send my objects over HTTP using my custom implementation? OR will java serialization just work OR are there better alternatives?
Advance thanks for your advise.
The good thing with standard Java serialization is that it produces binary stream which is quite a bit more space- and bandwidth-efficient than any of these XML serialization mechanisms. But as you wrote, XML can be more back/forward compatibility friendly, and it's easier to parse and modify by hand and/or by scripts, if need arises. It's a trade-off; if you need long-time storage, then it's advisable to avoid plain serialization.
I'm a happy XStream user. Zero problems so far.