I have a legacy database from which I have to extract some data and provide it as xml. For that I chose Symfony2 but now I am stuck. I would like to create one entity object, but the problem is, the data for it is distributed in two databases´(on the same server). I don't want to rewrite what I already made, so the easiest way would be to load the other database connections EntityManager in the existing repository. This is where I'am stuck. How can I load an EntityManager in a repository that uses the other connection? And what is the easiest way to "fill-in" the rest of the data of the entity? (By the way, I've used native queries in the repositories, because the legacy database is really complex and does not obey to any rules of DB design). I would be appreciate any help.
You could manage a second database connection called 'legacy', linking to the same database
than you need to map the entities to your managed connections than you could access your legacy table => entity and do whatever you want to with it ;)
http://symfony.com/doc/current/cookbook/doctrine/multiple_entity_managers.html
Related
Given your example:
https://github.com/corda/flow-db
I have a question.
Is it ok to create and store custom data within the Node database? Reading the Corda API Persistence section, I thought it could be used only to access the node database, and not to create new tables, etc. What would be a reasonable description of what can and what cannot be stored via CordaService?
It's totally OK to use Custom tables in Node. The ServiceHub actually provides you will a Connection Object. getServiceHub().jdbcSession(). As long as, you don't do some Update/Delete to the Nodes existing table you are fine. You can create any table you want and use it as per your need. As of now, corda doesn't expose JPA to map your tables to an Entity class. I guess you could see this feature in some future release.
I have created a new Entity in Dynamics 365 for Operations and I am trying to populate it using the Azure Logic App 365 for operations connector.
The logic app connector connects to the D365o instance and lists a large number of entities, but not the custom one I created. I have verified I am connected to the right instance by inserting data into one of the listed Entities and verifying the data.
I have looked at the properties on the Entity I created and nothing really stands out, public was set to yes by default and I have not touched anything else. Any ideas on what I could be missing in order to expose my custom Entity to the logic app connector?
Thank you
"I have looked at the properties on the Entity I created and nothing really stands out, public was set to yes by default and I have not touched anything else."
Does it mean that you left PublicCollectionName and PublicEntityName empty? Can you fill them in, recompile, refresh data entity list and try accessing your data entity again, using its PublicCollectionName?
I was looking through an old project and wanted to see if anyone had a suggestion on how to hide certain methods from being called by various layers. This was a 3 tier project, webapplication -> web service -> database
In the application there is a User object for example. When a User was being updated, the webapplication would create a User object and pass it to the webservice. The webservice would use the DataAccessLayer to save the User object to the database. After looking at this I was wondering if instead I should have made a Save method in the User class. This way the service and simply call the Save on the User object which would trigger the db update.
However doing it this way would expose the Save to be called from the webapplication as well, correct? Since the webapplication also has access to the same User object.
Is there anyway around this, or is it better to avoid this altogether?
There is a separation of concerns by keepeing the User object as object that only holds data with no logic in it. you better keep it separated for the following reasons:
As you stated, it is a bad practice since the Save' functionality will be exposed to other places/classes where it is irrelevant for them (This is an important for programming generally).
Modifying the service layer - I guess you are using WCF web service as you can transfer a .NET object (c#/VB) to the service via SOAP. If you put the saving logic in the 'User' object, you can't replace it another webservice that receives a simple textual data structures like JSON or XML or simply doesn't support .NET objects.
Modifying the data storage layer - If you want, for example, to store the data inside a different place like other database such as MongoDB, RavenDB, Redis or what ever you want, you will have to reimplement each class that responsible for updating the data. This is also relevant for Unit Testing and Mocking, making them more complicated to interrogate.
I use Fluent NHibernate code to create a MySQL database SessionFactory. No config files (just one value for the connection string in configuration - connectionStrings section of configuration file).
The SessionFactory creation code is contained in a Data tier class: SessionFactoryManager, which implements a singleton internal SessionFactory which is used by the Data and Business tiers to get all the sessions via SessionFactoryManager.OpenSession().
Some of my Business tier methods internally call SessionFactoryManager.OpenSession() to create sessions in a way that is transparent to the Presentation layer. So, when calling this methods there is no parameter or return value involving a session (to keep the Presentation layer "session-agnostic" when using those Business tier methods).
My problem comes when I write the integration tests for the Business layer: I would like to make them run on a SQLite in-memory database. I create a SessionFactoryManager which uses Fluent configuration to configure the SQLite database.
But when testing those methods that internally create the session, I can not tell them to use my testing SessionFactory (configured to use SQLite). So the "real" SessionFactory is called, and so the MySql database is used, not the SQLite.
I'm thinking of several possible solutions, but none of them seems right.
I could migrate the NHibernate configuration in Data layer to config files, and make different NHibernate config files for development/production and test environments, but I really would prefer to keep on with Fluent code.
I could also modify my Data layer to use a single configuration value, databaseMode or similar, that sets the database to be used: testing in-memory or the real one. And write some switch(databaseMode) statements like "case inMemory: { ... fluent code for in-memory SQLite... } case standard: { ... fluent code for standard database ... }". I don't like this approach at all, I don't want to modify my Data tier code functionality just for testing purposes.
Notice that I'm not testing Data layer, but Business layer. Not interested in testing NHibernate mappings, Dao or similar functionality. I already have unit tests for that, running OK with SQLite database.
Also, changing database is not a requirement of my application, so I'm not quite interested in implementing significant changes that allow me to dynamically change the DBMS, I only came to this need in order to write the tests.
A significant point: when using in-memory SQLite the database connection must be the same for all new sessions, otherwise the database objects are not available to the new sessions. So when creating a new session with SessionFactory.OpenSession() a parameter "connection" must be provided. But this parameter should not be used with non in-memory database. So the switch(databaseMode) should be used for any single session creation! Another Data layer code change that I don't like at all.
I'm seriously considering giving up and running my tests with the real database, or at least on an empty one, with its objects created and dropped for any test execution. But with this the test execution will surely be slower. Any ideas? Thanks in advance.
Finally my solution was Inversion Of Control: I changed my data tier so I can inject a custom SessionFactoryBuilder class that makes the Fluently.Configure(...) magic.
In my data tier I use the "real" MySqlSessionFactoryBuilder, in my test projects I write TestMySqlFactoryBuilder or TestSQLiteSessionFactoryBuilder classes, or whatever I need.
I still have problems with SQLite feature that requires that the same connection is used for all sessions, and must be passed as a parameter in every ISession.Open() call. By the moment I have not modified my data tier to add that feature, but I would like to do it in the future. Probably by adding to my SessionFactory singleton a static private member to store the connection used to make SchemaExport, and a static private boolean member like PreserveConnection to state that this connection must be stored in that private member and used in every ISession.Open(). And also wrap ISession.Open() and make sure that no session is opened directly.
I'm evaluating some technologies for a new Web Application. Which should use EF5 and Knockout JS with Web API. I wanted to take advantage of the OData feature, when returning IQueryable, but am currently running into the problem, how to convert my EF Models to my Business Models.
As far as I've read, if I want to have a more complex DB (Computed Columns, Stored Procedures, ...) I should use DB First approach. (Correct me if I'm wrong)
Because I need to use DB-First approach and want my models to be Independent of the DB, I need to create them additionally to the EF-Models. And when I return from the DataLayer my Business Model as IQueryable I loose the possibility to execute additional queries directly on the DB but instead they are executed on the ASP.Net server directly.
Of course I don't plan to run complex queries over OData and would anyway implement those as additional actions, but it might be useful on the slower clients (smartphones, ...) to limit the returned data and perform additional filters directly on the server.
Is there any way out of this dilemma, to be still able to use OData?
Regards
Peter
You can try using Code First and EF migrations to create/upgrade database. With migrations you can create custom migrations that can be just SQL scripts to achieve what can't be done automatically with Code First itself. Database First approach is fine as well.
Ask yourself if you really want to/need to support multiple backends. It is possible with EF but hard to maintain. In this case I assume your conceptual model (csdl) would be the same for all databases but you would have multiple store specific models (ssdl files). Since your model would be the same for all databases you would have the same C# types regardless of the database you are using.
When supporting multiple databases you won't be able to run SQL queries against the database (or to be more specific you will get exceptions if you run SQL query specific to one database against a different database) but ideally you should not need it. In the worst you could enclose the logic you would like to code in SQL in a stored procedure that would exist in all databases. Again, I don't know when this would be needed (the only thing that comes to mind is performance) but since you are planning using OData you wouldn't be able to run these queries anyways unless you start using Service Operations.
Since your conceptual model would be the same regardless of the database you would have the same types regardless of the database. You could try using these for both DataLayer and Business Model (especially if you go with POCO). An alternative would be to use POCO/DTOs. (I have not tried OData support in Web API but with WCF Data Services the service itself would actually use EF types so you would not be even able to tell the service to use different set of types).
You actually don't lose the ability with DB first models to execute queries against the business model, as long as your transforms aren't too bad. For example, I have a OData service which has a PersistedCustomer (DB model) and a Customer (Business model). With EF5, I can write the LINQ which transforms the IQueryable to IQueryable, query against the IQueryable and EF can translate the criteria back against the original database.