I'm learning to design a project using Hexagonal Architecture in java spring.
I have domain layer, entity jpa to connect to mysql and entity elastic to map with elasticsearch.
My main logic is when I update a product to mysql, I have to update it to elasticsearch also.
I have UpdateProductUseCase interface and a service to implement it. So I confuse about output ports. Should I design UpdateProductPort with 2 methods UpdateOrderToMySQL(), UpdateOrderToElasticsearch() or I will design UpdateProductToMySQLPort and UpdateProductToElasticsearchPort ?
Related
I have a use case where I need to create exact same postgresql database in two different regions. Everything is same in these two databases i.e same schema and same tables and same data.
I have a use to achieve distributed transaction. So if a request land in region-a and write to region-a database to let's say Person table, then exact same record must be either written in Person table in both these database or if there is any error, write attempt should be rolled back.
I am trying to figure out if I can attach two different datasources with same Person Entity and CRUD repository in spring so the respoistory.save() method can write to Person table in both the databases.
So far, I have come across AbstractRoutingDataSource but that is for achieving multi tenancy in the databases. Other solutions are found are slightly different where use case is to write different records in different database (mostly sharding based on various data points).
Does spring provide any out of the box solution so I can achieve transactional write to same table in two different databases.
Does spring provide any out of the box solution so I can achieve transactional write to same table in two different databases.
Depends on your definition of "out of the box" - it doesn't itself implement distributed transactions, but does have support for using libraries that do. It is however relatively complicated to get everything working correctly, and requires additional components to be carefully configured in your runtime environment.
Spring Boot 2.x documentation on distributed transactions is here: https://docs.spring.io/spring-boot/docs/2.7.x/reference/htmlsingle/#io.jta
The Spring Boot 3.x documentation is here: https://docs.spring.io/spring-boot/docs/current/reference/html/io.html#io.jta but it's also worth noting that for 3.x, the Spring Boot team have changed direction and decided that integrated support should be provided by the relevant JTA provider (cf. https://github.com/spring-projects/spring-boot/issues/28589 ), and so there's projects like https://github.com/snowdrop/narayana-spring-boot
I am creating a spring boot application and I only have one table in my oracle database (one table with more than 80 fields...), so, what is the best way to implement this in my spring boot-groovy app?
Do I need to have one entity with 80 attributes??
Can I have a hibernate entity model different from the awful oracle model? (having more than one entity in my app but connected with the same huge table).
Any ideas or tools are more than welcome.
Currently We have an enterprise application that works with spring and JPA.
Today we are planning our next generation server.
We are debating whether to use spring-data in our project? It seems to increase productivity and development times.
Are there any alternatives to spring-data to consider? Why not using spring and JPA alone?
What do you suggest?
Bear in mind we are starting to develop from scratch so no constraints are available other than:
we use mysql and mongoDB
we code in java
we will develop client side code in GWT.
Currently we have a layered architecture.
We have a Service layer and a manager layer, which takes care for persisting and business logic. Whoever built that didn't see a good reason to insert the third DAO layer.
There are some technical benefits of Spring Data over Spring + JPA, which in a pure SQL environment, I think give Spring Data an advantage:
Spring Data uses the same CrudRepository interface for all implementations, so you'll have less effort to switch between JPA to MongoDB
Spring Data saves you writing the same methods again and again. You just add the method to the interface and it'll generate it for you (e.g. UserRepository.findByUsername())
You can save boilerplate on REST implementations for JPA, MongoDB and others (see http://projects.spring.io/spring-data-rest/)
If you wanted to experiment with other persistence or indexing services, then there are Spring Data implementations for both mature and newer technologies such as for Neo4j, Hadoop, Solr, ElasticSearch, fuzzydb.
Given that you use MySQL and MongoDB, I think Spring Data is a strong candidate, as it allows developers to code to a single data access API (Spring Data) instead of two (JPA and the MongoDB Java Client).
Regarding the existing architecture, it sounds as though your manager layer is implementing either a Rich Domain pattern, or Active Record.
Spring Data is in my view very well suited to Rich Domain when combined with injection of services using Spring's #Configurable.
Lastly, I'd say that Spring Data also gives a significant advantage when needing to implement services for things like Spring Security and Spring Social, which use MongoDB or others instead of SQL.
We did this in the fuzzydb sample webapp that can be found here. (Disclaimer: I'm the currently sole recent committer on fuzzydb, and haven't touched it for a number of years, but we did have a live service, www.fridgemountain.com, based on that code, but neglected to promote it)
Is there an graph to object mapping framework for handling RDF? I would like to get some recommendations and any personal experiences.
Background Details:
I have an application that has been using Oracle, because of the dynamic nature of the data, we have decided to replace the oracle db with an semantic data store. I have written module to perform sparql queries and return Jena Objects. I would like to minimize the changes to other layers, so I was wondering if there is an framework in place, that I can substitute, for my existing Hibernate ORM layer. ( Present Architecture Oracle DB -> JPA (backed by hibernate) -> Session Beans (exposed as WS).
I have used the Entity Framework to start a fairly simple sample project. In the project, I have created a new Entity Data Model from a SQL Server 2000 database. I am able to query the data using LINQ to Entities and display values on the screen.
I have an Oracle database with an extremely similar schema (I am trying to be exact but I do not know all the details of Oracle). I would like my project to be able to run on both the SQL Server and Oracle data stores with minimal effort. I was hoping that I could simply change the configuration string of my Entity Data Model and the Entity Framework would take care of the rest. However, it appears that will not work at seamlessly as I thought.
Has anyone done what I am trying to do? Again, I am trying to write an application that can query (and update) data from a SQL Server or Oracle database with minimal effort using the Entity Framework. The secondary goal is to not have to re-compile the application when switching back and forth between data stores. If I have to "Update Model from Database" that might be ok because I wouldn't have to recompile, but I'd prefer not to have to go this route. Does anyone know of any steps that might be necessary?
What is generally understood under the term "Persistence Ignorance" is that your entity classes are not being flooded with framework dependencies (important for N-tier scenarios). This is not the case right now, as entity classes must implement certain EF interfaces ("IPOCO"), as opposed to plain old CLR objects. As another poster has mentioned, there is a solution called Persistence Ignorance (POCO) Adapter for Entity Framework V1 for that, and EF V2 will support POCO out of the box.
But I think what you really had in mind was database independence. With one big configuration XML that includes storage model, conceptual model and the mapping between those two from which a typed ObjectContext will be generated at designtime, I also find it hard to image how to transparently support two databases.
What probably looks more promising is applying a database-independent ADO.NET provider like the one from DataDirect. DataDirect has also announced EF support for Q3/2008.
http://blogs.msdn.com/jkowalski/archive/2008/09/09/persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx
The main problem is that the entity framework was not designed with persistence ignorance in mind. I would honestly look at using something other than entity framework.