I have a problem in the entity framework and looking for a solution, the problem is this :
imagine a software with one form that contains staff data,
now two users open the same record at the same time in their own systems to edit its data,
the first user changes the name and saves his edit,
some seconds after the first user, the second user changes the phone number and save his edit,
now which changes are registered in the database?
yes, the second change.
as you may found out my problem, I need a solution to allow both changes happen correctly in entity framework ORM.
do I must handle such things in the UI section, or there is a way in the entity framework itself?
thanks in advance.
Related
I have a SaaS platform where the user fills out a form and data entered into the form is saved to a database. The form UI has a large amount of config (originates from the DB but ends up in JavaScript) and business logic (in JavaScript). After a form is filled out and saved, the user can go back at any time and edit it.
The wrinkle is that an old form entry needs to behave like it did when it was first filled out - it needs the same config and business logic - Even if the SaaS has gone through a data schema change and changes to business logic since then.
To confirm, new forms filled out by the user would use the new/current data schema and business logic of course. But previous forms needs to behave as they did when they were created.
So I need a sensible way to version config, business logic and any dependencies.
The best I've come up with is, when the user saves their entry, to save the form's config as JSON along with the entry. When the user goes back to edit an old entry, I do not load the config from current database schema but simply dump the JSON config that was saved with the entry.
For the business logic, I save a system version number along with the entry, for example "01". When the user loads an old form, I check the version of the entry and I then load the form JavaScript from a path like "js/main_01.js". When I make a non-backwards-compatible change to the business logic, I increase the system's version number to, for example, "02". New forms would then use "js/main_02.js". I also use this cheap versioning approach for HTML view templates which is getting hairy.
This approach works but it seems a bit flimsy or homegrown. I'm trying to avoid conditionals in my business logic like if version==2: do this. This approach avoids that but also has it's downsides.
I don't think the stack really matters for this convo but just in case, I'm using django/mysql.
You're likely to get a tremendous amount of "opinion" on this, and no real clear answer.
You could develop an API to your config and logic in may ways, with versioning saved with the submitted data, thereby requiring an API-Manager solution.
However, you could instead store the entire DOM object in the record that the data was stored, thereby creating a static page that is recalled and resubmitted at will, with separation between view and model.
I'm building an ASP.NET MVC application with SQL Server. I would like to know what will be a good practice for record deletion operations. I mean, when an item is deleted via web application, I would like to mark it as deleted, and then from an admin console, I will purge them if needed.
Is this a good practice? Should I use or avoid?
Thank you.
There is nothing wrong with this approach if you have no issues with storage space. Typically, we will use this pattern if the object being deleted is tied to other object (for instance, if you were tracking changes by user id, then you would not want to delete the user because you would not be able to pull info for that user later on). Simply mark a bit field showing the record has been deleted and filter those out when you query.
Again, it really depends on what makes sense for you and your application. Will you ever need this object again? Is it tied to other items in the database? Do you want to offer the user the option to 'undelete'? If the answer to any of those questions is yes, then you should probably keep the record. If the answer to all of those is no, then I would ask, why would you not just delete the record at the time it was requested?
I am developing a system with Java EE and JPA where users can make changes to entities. It is needed to trace back to the changes when needed. So the all the changes and the user have to be recorded for each occasion when en update is made. What is the best way to record the changes.
For example, there is an Entity called Investigation. It has attributes like Name, Category, Price, Volume, etc. A user can search a single investigation and change the name in one instance and in another instance, another user can change the price. All these occasions with the change done and the user who did it is needed to be traced back when needed.
One method described in this link is that to label objects as old edited and create a new object with updated values, but the problem there are several other objects from different entities referring to the old one.
Another method as described in this link is to use a versioning field in a new table. Than can be achieved in JPA by creating a new entity that extends the main entity.
Out of these methods what is the best practice? Is there any other optimized way to keep the record editing history in Java Persistence?
EclipseLink supports history.
See,
http://wiki.eclipse.org/EclipseLink/Examples/JPA/History
If you don't mind using Hibernate, Envers might be interesting for you. It performs auditing automatically, optionally appending metadata like current user.
For each audited entity it creates a history table that holds previous versions.
I'd like to log all changes made an SQL Azure database using Entity Framework 4.
However, I failed to find a proper solution so far..
So far I can track all entities themself by overriding SaveChanges() and using the ObjectStateManager to retrieve all added, modified and deleted entities. This works fine. Unfortunately I don't seem to be able to retrieve any useful information out of RelationshipEntries. In our database model we some many-to-many relationships, where I want to log new / modified / deleted entries too.
I want to store all changes in an Azure Storage, to be able to follow changes made by a user and perhaps roll back to a previous version of an entity.
Is there any good way to accomplish this?
Edit:
Our scenario is that we're hosting a RESTful WebService that contains all business logic and stores the data in the Azure SQL Database. A client must be authenticated as a user with the WebService, and I'd need to store the information which user changed the data.
See FrameLog, an Entity Framework logging library that I wrote for this purpose. It is open-source, including for commercial use.
Even if you don't want to use the library, you can look at the code to see one way of handling logging relationships. It handles all relationship multiplicities.
Particularly, see the code for the private methods logRelationshipChange, and logForeignKeyChange in the ChangeLogger class.
You can do it with a tracing provider.
You may want to consider just using a database trigger for this. Whenever a value in a table is changed, copy the row to another Archive table. It has worked pretty well for me.
Hi i am developing an App in WPF who will have paginated records (i am doing the pagination myself depending on the filters or in the number of records per page the user wants to be shown).
So i have never worked serious with DataGrids and what i am asking is, what is the best approach and better politic when we work with a DataGrid to update the Table in the DB?
We detect the row who have been changed, or we update the whole Table in the DB, what is the better way?
Because the user can change one row, and then other, and imagine the user changes 50 rows, the App will have to connect 50 Times with the DB?
Unit of work is probably the most common infrastructure solution to this problem, basically it stores the changes applied to the data and when ready executes them in a transaction to the database. There are many ORM mappers like Entity Framework or nHibernate that already do this for you, so id start there.
EDIT
See this example implementation as it sounds like from your comments yould need to write your own version, but basically you build a list of inserts, updates, deletes that should happen and execute them all in a trasaction, first inserts, then updates, then deletes but Id recommend you look at an ORM like the ones i described above they already have this as a feature.