There are Object Mappers for JPA support for NoSQL databases like Mongo, Couch in Hibernate OGM, Spring Data. But, I could not able to find any reliable and actively developed framework for Dynamodb.
I looked spring-data-dynamodb, but it is stated that:
Due to external time and project commitments, I'm no longer able to continue active development of this project as of January 2016. Thank you to everyone involved in shaping the project over the past few years and thanks to all those who have raised issues and submitted pull requests over the time.
This lack of support causes model integration problems with widely used Java MVC frameworks.
Could you please explain me the technical details, why there is not a complete Dynamodb Object Mapper for JPA support?
Related
I am evaluating Sails.js as potentially the most closely aligned alternative for a migration of about four years of development on the Wakanda JS full stack platform. I would appreciate perspectives from the Sails.js community based on the following overview:
AS-IS: WakandaDB, Node.js / SSJS / Node Workers / Shared Workers; Client side: Angular 5 for Web and for Ionic/Cordova hybrid mobile apps.
Wakanda DB and Wakanda API and dataclass / dataclass method architecture and all of its off the shelf capabilities will no longer be in play.
It seems that Sails.js is the most closely aligned to my current technology stack. Does the community agree with this? I understand the community is pretty large, but I do not see evidence of this in terms of books on Amazon (as compared to the Meteor platform for example).
Appreciate perspectives and any references to migration related guides/references.
Kirk
I'm using sails.js professionnaly for four years now.
I worked with version V0.12 and now V1.0.
I've never heard of the Framework Wakanda so i can't tell you if the technology stack match.
All i can say is Sails.JS have strenghs and weaknesses.
I will just give you the cons so you can see if this is a no go for you.
The community is not the most active, a lots of good stuff developed for v0.12 isn't ready for v1.0 after years (i'm thinking of sails-auth and sails-permissions who provide good ACL structure).
He could be to big for small projects but i don't think it's a problem for your needs.
He works great with MongoDB but not that much with other DB system (even if community developed adapters for other DB as postgresql).
And for me the biggest weakness of this framework is his ORM.
This one will play with your nerves, you will have to rewrite some parts like the one who create the criteria of the query from express req and set default limit to your query even if you don't ask it.
I you don't use mongo, don't use the migration script provide by the adapter and build your own with db-migrate.
So i will recommend Sails JS for project with complex API but simple DB structure.
Hope this will help you in your choice ;)
So I have been using Hapi Fhir Server (for several years) as a way to expose proprietary data in my company....aka, implementing IResourceProvider for several resources.
Think "read only" in this world.
Now I am considering accepting writes.
The Hapi Fhir Server has this exert:
JPA Server
The HAPI FHIR RestfulServer module can be used to create a FHIR server
endpoint against an arbitrary data source, which could be a database
of your own design, an existing clinical system, a set of files, or
anything else you come up with.
HAPI also provides a persistence module which can be used to provide a
complete RESTful server implementation, backed by a database of your
choosing. This module uses the JPA 2.0 API to store data in a database
without depending on any specific database technology.
Important Note: This implementation uses a fairly simple table design,
with a single table being used to hold resource bodies (which are
stored as CLOBs, optionally GZipped to save space) and a set of tables
to hold search indexes, tags, history details, etc. This design is
only one of many possible ways of designing a FHIR server so it is
worth considering whether it is appropriate for the problem you are
trying to solve.
http://hapifhir.io/doc_jpa.html
So I did this download (of the jpa server) and got it working against a real db-engine (overriding the default jpa definition).....and I observed the "fairly simple table design". So I am thankful for this simple demo. But looking at the simple, it does concern me for a full blown production setup.
If I wanted to setup a Fhir Server, are there any "non trivial" (where above says "fairly simple table design") ... to implement a robust fhir server...
that supports versioning (history) of the resources, validation of "references (example, if someone uploads an Encounter, it checks the Patient(reference) and the Practitioner(reference) in the Encounter payload......etc, etc?
And that is using a robust nosql database?
Or am I on the hook for implementing a non-trivial nosql database?
Or did I go down the wrong path with JPA?
I'm ok with starting from "scratch" (an empty data-store for my fhir-server)....and if I had to import any data, I understand what that would entail.
Thanks.
Another way to ask this.....is......is there a hapi-fhir way to emulate this library: (please don't regress into holy-war issues between java and dotnet)
But below is more what I would consider a "full turn key" solution. Using NoSql (CosmoDB).
https://github.com/Microsoft/fhir-server
A .NET Core implementation of the FHIR standard.
FHIR Server for Azure is an open-source implementation of the
emerging HL7 Fast Healthcare Interoperability Resources (FHIR)
specification designed for the Microsoft cloud. The FHIR specification
defines how clinical health data can be made interoperable across
systems, and the FHIR Server for Azure helps facilitate that
interoperability in the cloud. The goal of this Microsoft Healthcare
project is to enable developers to rapidly deploy a FHIR service.
With data in the FHIR format, the FHIR Server for Azure enables
developers to quickly ingest and manage FHIR datasets in the cloud,
track and manage data access and normalize data for machine learning
workloads. FHIR Server for Azure is optimized for the Azure ecosystem:
I'm not aware of any implementation of the HAPI server which support a full persistence layer in NoSQL.
HAPI has been around for a while, the persistence layer has evolved quite a bit and seems to be appropriate for many production scenarios, especially when backed by a performant relational database.
The team that maintains HAPI also uses it as the basis for a commercial offering, Smile CDR. Many of the enhancements that went into making Smile CDR production ready are baked into the HAPI open source project. There has also been some discussion on scaling the JPA implementation.
If you're serious about using HAPI in production I'd recommend doing some benchmarks on the demo server you set up that simulate some of your production use-cases to see if it will get you what you want, you may be surprised. You can also contact the folks at Smile CDR as they do consulting and could likely tell you more specifically how to tune an instance to scale for your production priorities.
You can use Firely's implementation of FHIR. The most used repo is the FHIR SDK;
https://github.com/FirelyTeam/firely-net-sdk
But if you want more done for you out of the box you can use their Spark repo. This uses the SDK underneath and ultimately gives you a IAsyncFhirService which you can use for CRUD operations;
https://github.com/FirelyTeam/spark
And to your question; Spark currently only supports Mongo DB as the data persistence layer i.e. there is no entity like mapping done to create a db schema in a relational database. NoSQL I think made sense in this case.
Alternatively, check out the list of FHIR implementations in other languages maintained by HL7 themselves;
https://wiki.hl7.org/Open_Source_FHIR_implementations
I am working on a new project which is to use Asp.net MVC 5 and Cassandra.
I am very OK working with entity framework.
Is there a way of connecting entity framework to a Cassandra database?
If not, can anyone help me with the necessary structures to have my MVC 5 application work with a Cassandra database?
More especially is the fact that i want to work with the MVC 5 identity.
I'll really appreciate any help.
All the old versions of EF, up to version 6.x, don't support NoSQL databases like Cassandra.
EF7 is still under development, but it's being designed to be flexible enough to support NoSQL databases. As of today, (Nov 2015) there isn't still any support for a NoSQL database in the current EF7 beta8. But we can expect to see it in the future.
For example you can see it mentioned in this article of MSDN magazine: Looking ahed to Entity Framework 7:
Beyond Relational
When Entity Framework was first introduced, Microsoft had a vision of it being used for a variety of data stores, though the first pass focused on relational databases. Non-relational databases existed at that time, but were not widely used, unlike the NoSQL databases—especially document databases—that are so popular today.
While EF is an Object Relational Mapper (ORM), developers who use it want to be able to use the same constructs to interact with non-relational databases. EF7 will provide a high level of support for this, but keep in mind what high level really means. There are vast differences between relational databases and non-relational databases and EF will not make any attempt to mask those differences. But for basic querying and updates, you’ll be able to use the patterns with which you’re already familiar.
I'm writing a business application using Entity Framework and there are some things that I need like:
transaction and transaction scope management **
data filtering
control over refreshing data from the db (eg. every 15 s)
be able to manage what changes are being made to the data and to be able to undo some of them
Those things aren't supported in any way by Entity Framework (or at least it's not easy to accomplish it).
Are there any libraries that sit on top of EF and can do that (or maybe they have their own ORMs) ?
Do I really have to implement that myself?
** I mean something like: I have an object and want to do some changes to it - I start a transaction and every change that is done from that point in time is included in the transaction, then I commit and that's all that gets commited to the db - other objects live their own happy lives.
Wouldn't any standard ORM do all that for you? Both Hibernate and SQLAlchemy (the big ones I've worked with so far) will do all that stuff for you. They both support transactions, versioning, filtering is straightforward and both support rollbacks during transactions.
For rapid business application development, have a look at Spring Roo, Entity Framework sounds like something that is not ready for the market, Spring is.
Quote from wikipedia: The first version of Entity Framework (EFv1) was included with .NET Framework 3.5 Service Pack 1 and Visual Studio 2008 Service Pack 1, released on 11 August 2008. This version has been widely criticized, even attracting a 'vote of no confidence' signed by several hundred developers.
want to develop my project on Google App Engine .I want to use google big table as database. For the database I have two options JPA and JDO. Will you guys please suggest me on it? Both are new for me and I need to learn them. So I will be focused on one after your replies.
Since you're using Data Nucleus, see their FAQ on JDO vs JPA. http://www.datanucleus.org/products/accessplatform_3_0/jdo_jpa_faq.html
DataNucleus AccessPlatform supports both JDO and JPA specifications of Java persistence. As such it has no "vested interest" in either technology, believing that it is for users to choose which they like best. There has been much FUD on the web about JDO and JPA, largely perpetrated by RDBMS vendors. This FAQ corrects many of these points
A key difference is that JDO support a rich domain model (logic together with data), in fact all persistent classes can have a reference to the current PersistenceManager, issue queries, and, I guess, it's possible not to have fields persistent by default.
JPA does not support such software design. In fact each Entity doesn't have a reference to the PersistenceManager, to have it you have to resort to ThreadLocal variables, which is not a very elegant and robust solution.
Since GAE BigTable is not an RDBMS, JDO is a better choice. There are some detailed comparision articles in Aphache JDO, it is helpful for me.
JPA persists java objects to relational data via ORM, while JDO is more general specification for java object persistence. So using JDO will give you more freedom in storage implementation options for your objects.
JPA is the leading java standard for persistence. So I'll say use JPA if you are using RDBMS and require ORM.
Hibernate is generally used as JPA implementation. If you need some extra features you can use hibernate specific annotations.
This question already looks to be discussed here JDO vs JPA for Java on Google App Engine