We have a requirement for building a database crawler. The application parses the tnsnames, connects to each database and retrieves some information like version, accounts, etc. We are trying to use JPA across the other parts of the application and to persist this data into the application's database.
So far, I only see creating an EntityManagerFactory programmatically for every database. Is there any other options?
We are using Spring, are there any benefits that Spring brings to the table in this scenario?
Thanks
JPA is clearly not the right tool for this job. JPA allows creating functional entities mapping a well-know database schema. Your tool doesn't know anything about the schemas and tables it will find. There could be 0 tables or 5000, with completely unknow names.
You need a much lower-level API to do what you want, like JDBC.
You could use JPA to store the results of your crawlings in a single schema, though.
Related
In my asp.net core application, each client has their own database schema.
Hence there are many databases. Sometimes the tables and fields will be different.
I have used Entity Framework core as ORM and we are following Generic Repository pattern.
Is there any option to generate DB Context at run time corresponding to each client?
Thanks
Krishnan
I am curious to know that if Entity framework can create tables in other databases besides MS-SQL ??
Moreover, is there any provision to create XML schema through EF ?
Under the hood Entity Framework uses providers that are specific for different databases. So it depends on a provider whether EF can create tables or not. However, I haven't heard about providers that do not have this possibility. The easiest way to be sure is to write a simple program with a few lines of code.
As to XML schema. Are you asking about using XML files instead of database as the storage for your data? If so, again it depends on the provider. If you want you can theoretically create one that will use XML files. However, I haven't tried to do so and I don't think that it is a good idea. There are technologies that fit here better (see this question).
I'm working on a green-field application that has a corporate mandate that Stored Procedures are used for all database interaction.
I'd like to use Entity Framework and leverage Stored Procedure Mapping to gain the benefits of the ORM.
Since we will be developing the database and .NET application in parallel, I'm looking for information to help the database developer/administrator. Does anyone know of a consolidated guide on how to design tables and stored procedures so they can be best integrated with the Entity Framework?
A couple tips I've collected are:
Update Stored Procedures require exactly 1 parameter per table column
There must be an insert, update, and delete Stored Procedure for every table
I want to know as much about how the database should be designed for easy use with Entity Framework because the database is very difficult to change later in our environment.
I wrote a blog post describing the limitations of using mapping in this way after working on this for several months:
The Pitfalls of Mapping the Entity Framework to Stored Procedures
If you want to use Stored Procedures are used for all database interaction, I just don't see the need to use Entity Framework. One good reason of EF is to save time to write T-SQL, and if you don't take advantage of this, why even use EF?
Could someone give me an explanation of if what I'm doing makes sense?
I am currently developing a Java EE application using MVC architecture, and MongoDB as my database. What I have is several entities written as Java objects with custom mapping methods to persist to and from my MongoDB, as well as a separate controller class to perform Database queries and operations. I am able to store these entities in my session with no problem, but I haven't tested this on a larger scale. I've tried annotating my objects as beans, however I received errors.
My typical method of transmitting data is to query my MongoDB, receive the information, map it to a java object, and store it in a session to be accessed by the front end. Is this the proper way to go about this?
Do my entities need to be EJBs? What do I have to gain from making them EJBs? I'm sorry if this question is presented poorly and seems unintelligent. I just want to have a better understanding of the technology I am trying to utilize before further developing. Most of the reading I have done on such topics has been to no avail. If anyone has some clear reading or an explanation that should help me understand what I am asking, it would be most appreciated.
I assume by "EJBs", you are referring to "Entity Beans"? In EJB 3, entity beans are "replaced" by JPA. Think of JPA as a "specification" for ORM frameworks. JPA/ORM are frameworks for mapping Java objects to and from relational databases. You are using MongoDB, which is not a relational database, and hence not that suitable for JPA. So I would say no, there is no need for you to consider JPA. Instead you should consider other frameworks, like Spring Data, which can simplify the task you are doing.
in my opinion you can use EJB3 with mongodb without JPA and entity manager, but you will have Stateless/Singleton/Startup/MDB beans with 0 configuration and with perfect managable backend.
Is it possible to use Entity Framework 4.3 without linking the model to an actual DB in the back-end?
I need to build a conceptual model of a database in the VS designer and then I'd like to manually handle fetches, inserts and updates to various back-end databases (horrible legacy systems). I need to be able to do this without EF moaning about not having tables mapped, etc. I realise that this is a very odd thing to want to do...
The reason for this is that we would like to move from these legacy systems into a well designed data model and .NET environment, but we need to still maintain functionality and backward compatibility with the old systems during development. We will then reach a stage where we can import the old data (coming from about 6 different databases) into a single DB that matches the EF model I'm building. In theory, we should then be able to switch over from the hacked up EF model to a proper EF model matching the new data structure.
Is this viable? Is it possible to use the EF interface, with LINQ without actually pointing it to a database?
I have managed to query the legacy systems by overriding the generated DbContext and exposing IQueryable properties which query the old systems. My big fight now is with actually updating the data.
If I am able to have EF track changes to entities, but not actually save those changes. I should be able to override the SaveChanges() method on the context to manually insert into various legacy tables.
I'm sort of at wits end with this issue at the moment.
UDPATE 4 Sept 2012: I've opted to use the EDMX file designer to build the data model and I generate the code by using T4. This enables me to then manually write mapping code to suit my needs. It also allows me to later perform a legacy data migration with relative ease.
If I were in your situation I'd setup the new DB server and link the legacy servers to it. Then create stored procedures to interface with EF for the INSERT/UPDATE/DELETE. This way your EF code remains separate from the legacy support messiness. As you decommission the legacy DB servers you can update your stored procedures accordingly. Once you have no more legacy DB servers you can either continue using your sprocs or do a refresh of your EF data connection to use the table schema directly.
Entity framework is to link entities to a data store without manual populates.
Otherwise you're just using classes with linq.
If you mean you don't want a seperate data store like sql server, mongo etc etc, then just let your application create the database as an mdb file that gets bundled in your app_data file. That means you don't need a databsae server so to speak and the database is part of your app.
If on the other hand you want a different way to save to the database, you can create your own data adapters to behave however you like. The mongo .net entity framework component is an example of this.
Alternatively, using code only you can just use stored procedures to persist to the database which can be a bit verbose and annoying with EF, but could bridge the gap for you you and allow you to build a good architecture with a model you want that gets translated into the crappy one in your repositories.
Then when the new database is ready, you can just rework your repo's to use savechanges and you're done.
This will of course only work with the code only approach.