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.
Related
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.
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.
Consider the client application that should store its data on remote server. We do not want it to access this data "on-fly", but rather want it to have a copy of this data in local database. So we do not need connection with remote server to use application. Eventually we want to sync local database with remote server. The good example of what I am talking about is Evernote service. This type of applications is very common, for instance, in mobile development, where user is not guaranteed to have permanent Internet connection, bandwidth is limited and traffic can be expensive.
ORM (object relational mapping) solutions generally allows developer to define some intermediate "model" for his business logic data. And then work with it as some object hierarchy in his programming language, having the ability to store it relational database.
Why not to add to an ORM system a feature that will allow automatic synchronization of two databases (client and server), that share the same data model? This would simplify developing the applications of the type I described above. Is there any systems for any platform or language that have this or similar feature implemented?
this links may provide some useful information
http://gwtsandbox.com/?q=node/34
http://www.urielkatz.com/archive/detail/google-gears-orm-v01/
http://www.urielkatz.com/archive/detail/google-gears-orm/
AFAIK, there are no such ORM tools.
It was one of original goals of our team (I'm one of DataObjects.Net developers), but this feature is still not implemented. Likely, we'll start working on database sync this spring, but since almost nothing is done yet, there is no exact deadline for this.
There is at least one Open Source ORM matching your needs, but it is a Delphi ORM.
It is called mORMot, and use JSON in a stateless/RESTless architecture to communicate over GDI messages, named pipes or HTTP/1.1. It is able to connect to any database engine, and embed an optimized SQlite3 engine.
It is a true Client-Server ORM. That is, ORM is not used only for data persistence of objects (like in other implementations), but as part of a global n-Tier, Service Oriented Architecture. This really makes the difference.