I want to export all records into csv file for the given table. So need to Fetch corresponding repository for the given entity class. So give me solution.
Related
We have 2 druid instances one for Stage and Data validation and another for Production. Once data is loaded and validated on stage instance we need to migrate it to production. Is there a way we can migrate data directly to other instances instead of reloading?
Well, in theory the only thing you need is the segments data records and the raw data files. If you store your metadata in (for example) MySQL, you can export the records from the druid_segments table.
The druid_segments record will also show you where the segment file is stored (see the payload column.
You now should copy the data files to the location which is used in production. Make sure that the payload column "points" to this correct location.
Now import the records in your production environment and you should be settled.
Before applying this in production please test this in a test environment.
Maybe this page will help you along. It contains useful information for your situation: https://support.imply.io/hc/en-us/articles/115004960053-Migrate-existing-Druid-Cluster-to-a-new-Imply-cluster
We are trying to pull historical test coverage data (more like weekly/mothly trend) for a given resource. At a project level we are able to fetch required data by using the API https://sonar-service/api/resources?resource=com.demo.project:demo-project&metrics=new_coverage&includetrends=true.
But the same is not working if we try to fetch information at a class level (https://sonar-service/api/resources?resource=com.demo.project:demo-project:src/main/java/com/demoClass.java&metrics=new_coverage&includetrends=true). It simply returns current value.
Is there any way to fetch historical coverage data for a given class/method (either by using APIs or querying Database).
If it is not possible in Sonarqube 5.x & below, do we have any simpler way in 6.x version of Sonarqube.
Historical data is not retained at the file level. I don't believe it ever has been.
I've found that you cannot actually delete an entity, so I was thinking of doing a jhipster utility to delete entities (and find for relations, then cut them too), and if said searching works then add one to change an entity name.
That said, I was looking where I can find in jhipster generator the files that take domain over the file creation.
JHipster supports deleting an entity as its repositories extends JpaRepository, and its generated REST controllers also expose a delete action.
So this is a question about Serialization and Versioning. I have a program that is a Music database that stores sheet music with Name, Composer, ...
I serialize each song to a hidden folder so that the user can reload the database at next launch.
Now, when I have to change something in the Song class all is fine if it is a compatible change. I had the idea that if I were to make an incompatible change, would I be able to create a second class with the same name 'Song' but a different VersionUID. Then when it reads the Songs, if the saved version doesn't match the latest version, it will go to a method that will read the Song into the old UID then go through a series of steps to convert it to the new Version. Is any of this possible?
I do know that you can have multiple methods with the same name but different parameters. Would this work with classes and VersionUID's or some other variable?
Thanks!
No it would not. Classes do not support a concept like "property overload" so a class with the same name is considered as the same class, even if it has different properties.
The "best" way for you would be a migration to a relational database in combination with EntityFramework6 (there is a SQLite adapter out there, so you don't need SQLServer).
With EF you can use migrations which enables you to change your model and migrate the data automatically. If done correctly you can change the model and no data loss occurs.
We are creating a system that allows users to create and modify bills for their clients. The modifications need to be maintained as part of the bill for auditing purposes. It is to some extent a point in time architecture but we aren't tracking by time just by revision. This is a ASP.NET MVC 5, WebAPI2, EntityFramework 6, SQL Server app using Breeze on the client and the server.
I'm trying to figure how to get back the Breeze and our data model to work correctly. When we modify an entity we essentially keep the old row, make a copy of it with the modifications and update some entity state fields w/ date/time/revision number and so on. We can always get the most recent version of the entity based off of an entity ID and an EditState field where "1" is the most current.
I made a small sample app to work on getting Breeze working as part of the solution and to enable some nice SPA architecture and inline editing on the client and it all works... except that since our entity framework code automatically creates a new entity that contains the modifications, the SaveChanges response contains the original entity but not the new "updated" entity. Reloading the data on the client works but it would of course be dumb to do that outside of just hacking around for demo purposes.
So I made a new ContextProvider and inherited from EFContextProvider, overrode the AfterSaveEntities method and then things got a bit more complicated. Not all the entities have this "point in time" / revision functionality but most of them do. If they do I can as I said above get the latest version of that entity using its EntityId and EditState but I'm not seeing a straight forward way to get the new entity (pretty new to EF and very new to Breeze) so I'm hoping to find some pointers here.
Would this solution lie in Breeze or our DataContext? I could just do some reflection, get the type, query the updated entity and shove that into the saveMap. It seems like that might break down at some point (not sure how or when but seems sketchy). Is our architecture bad? Should we have gone the route of creating audit/log tables to store the modified values instead of keeping the datamodel somewhat smaller by keeping all of the revisions of the entities in their original tables but with the revision information and making the queries slightly more complicated? Am I just missing something in EF?
... and to head of the obvious response, I know we should have used a document database but that wasn't an option on this project. We are stuck in relational land.
I haven't tried this but another approach would be to simply change the EntityState of the incoming entity in the BeforeSaveEntities method from Modified to Added. You will probably need to also update some version field in this 'new' entity so that it doesn't have a primary key conflict with the original.
But... having built apps like this in the past, I really recommend another approach. Store your 'historical' entities of each type in a separate table. It can be exactly the same shape as the 'current' table. When you save you first copy the 'current' entity into the 'historical' table ( again with some version numbering or date schema for the primary key) and then just update your 'current' entity normally.
This might not give you the answer you expected, but here is an idea:
When saving an object, intercept save on server, you get an instance of object you need to modify, read object from database that has the same ID, put copy of that old object to legacy table in your database and continue with saving into main table. That way only latest revision stays in main table while legacy table would contain all previous versions.
So, all you would need to do is have two tables containing same objects:
public DbSet<MyClass> OriginalMyClasses{get;set;}
public DbSet<MyClass> LegacyMyClasses{get;set;}
override SaveChanges function and intercept when entry E state is Modified, read E type, get the original and legacy tables, read object O from Original with same ID as E, save O to Legacy table, and finally return base.SaveChanges(); (let it save as it is supposed to by default).