What happens if i delete an entity that has already been trained - watson-knowledge-studio

I want to delete an entity out of 4 other entities on knowledge studio, ibm watson but im scared it will break it?
Will my other entities still work ?

If you already executed ML training and have a ML model, it is good way to save current trained model as a version before you delete the entity type (by "Create Version" button in "Machine Learning Model" > "Versions" view). The saved ML model is not affected by entity deletion, meaning that the model contains the entity type.
Note that the non-saved trained model is affected the entity type deletion.
The other entity types and their annotations still work even after the entity type deletion. Additionally, you can revert the saved model and entity definitions by promoting the saved version (by "Promote" button in the Versions view).

Related

How to debug problems with The Entity Data Model Designer (Entity Framework)

I have inhereted some project which uses Entity Framework in a way which makes it hard to make there any changes. It uses QueryViews for almost all tables (cca 50 tables) and of course stored procedures. Now I have to change there quite a lot of things ... rename tables, add tables, change columns etc.
When I tried to use the "Update Model from database ..." wizard, than after the update (where I added/removed the tables and let refresh the others using the wizard) from the database the Entity Data Model Designer rendering stops working ... there is just blank window with the text "The Entity Data Model Designer is unable to display the file you requested."
So I tried different approaches (like manually editing the edmx file), but the problem remains. The editor shows only the "The Entity Data Model Designer is unable to display the file you requested."
The mapping using QueryViews makes it probably more complicated. It is well known that the designer can not work with the QueryViews properly (one can not edit them using the designer) and the Entity framework engine even does not recognize that the columns from CSDL are mapped using the QueryViews and complains on each and every column (which is mapped using QueryView) that "Error 11009: Property 'XXX' is not mapped." I see exactly 100 errors like this. Maybe somewhere after the 100th error, there is some hint (in the form of other errors) how to fix the issue with Designer, but I don't know how to see them. The 100 limit is most likely hardcoded in VS2010 (http://stackoverflow.com/questions/2880936/how-to-increase-error-limit-in-visual-studio).
Btw. the code (classes for entities etc.) is generated without problems.
So, the question is:Is there a way how to see some log or something, where would be noted why the Entity framework Data Model Designer is not able to render anything?
Or is there at least some way how to see the rest of the errors (besides the 100 errors)?
Or does anybody know the ideal way of dealing with updating schema in EF besides using the wizard?
Try to add new EDMX and right click >> open with >> XML editor, then you can see a complete set in an empty model definition in EDMX. So you can compare the two EDMX and check notice which part of the EDMX is missing.
Here is the error link
In the end I have just do all the changes manually by editing the xml. However, I used the model designer (the GUI integrated in VS for EF) for creating the whole CSDL layer. So my approach was to carefully choose tables in the correct order and add them one by one in the multiple iterations of the following steps:
Use the model designer to create the csdl layer for the chosen table including all relations with already existing table. This at least ensured that the designer was usable later on and it saves the manual writing of the CSDL objetcs.
Write the SSDL layer, which should reflect the DB table.
Write the mapping layer (in my case using the QueryViews).
Try to compile and resolve all compile errors.
Repeat for next table (or more tables if you find it easier).
I hope this will help somebody.

CRM 2011 Entity modelling. Creating custom entity based on OOB entity

I'm just looking for a bit of clarity on the correct way to model custom entities and activities in CRM 2011.
I have to model a custom activity which is called a Submission. It is really just a Case with some additional properties.
When creating this in my Solution, is it best practice to base it on the Case Entity and then add the properties, or would it be better to create a new activity instead?
We have other types of activities which are similar, so I would also be basing them on the Case entity if that's the best way to go.
Many thanks,
John
I usually err on the side of creating a new custom entity (or activity), especially if you think you might have "case types" that are significantly different. It isn't fun writing a bunch of javascript that shows/hides fields based on type.
You might pick the one activity type (perhaps Submission) that is most like a "Case" and then create custom activities for the others that are close. But then you'll have subtle differences (the Customer lookup on Case, for example, can be either a Contact or Account, but you can't add your own "Customer" lookup to your custom entities).
Unless you really need something that the built-in Case entity provides that you can't do yourself, my vote would be for new entities (activities) and then just hide the built-in Case entity by security roles.

Making entity framework treat views with many-to-many relationships, like it does tables with many-to-many relationships

I have three views that I've manually created in the DB.
First view is "Region", the second is "FIPS" and the last is a many-to-many between them called "Region2FIPS". These are all views, and I only need read access the data, so I'm not worried about having updateable views.
I have added each of these views to Entity Framework, and created the appropriate associations between them.
Region to Region2FIPS is a 1 to many.
FIPS to Region2FIPS is a 1 to many.
The "Region2FIPS" view contains only two columns, one called "FIPSID" the other "RegionID". These column are associated with their respective views in the relationships I defined above.
When this type of association is made on tables in the DB, Entity Framework knows that it is a many-to-many relationship and it creates a navigation property on "Region" called "FIPS" that I can use to navigate through the child collection of FIPS. It does likewise for "FIPS" to "Region".
However, when done manually, with views, it does not exhibit that behavior. Instead, my "Region" object has a collection of "Region2FIPS" objects, which each have a navigation property called "FIPS" which is of type "FIPS". And my "FIPS" object has a collection of "Region2FIPS" objects, which each have a navigation property called "Regions" of type "Region".
I assume this has something to do with the fact that I can't create foreign key references on the views, so entity framework doesn't realize the many-to-many relationship. But I thought that if I manually created the many-to-many relationship between the views it would recognize it and properly handle the navigation between the types. Is there a way for me to force it to do this?
It's possible, but the designer doesn't really help you here. You have to do the mapping manually.
One fairly easy way is to use Code First mapping. But this means your model has to be Code First to begin with. If you're writing a new model, just do that.
If you're using DB First mapping, however, you will have to do the mapping manually. Your SSDL will probably already be correct, once you define the "primary keys" of the views. You would then have to remove the "Region2FIPS" objects from the CSDL (not just from the designer!) and manually patch up the MSL.
Perhaps the easiest way to do this would be to use the designer to automatically map real DB tables (not views) with a similar schema and then replace the table names with view names in the EDMX, using the XML editor.

Quick method to correct Entity Framework's missed "singularizations"?

Given the need to "Update Model from Database" fairly frequently from the .edmx diagram, is there a way to modify the rules by which Visual Studio attempts to "singularize" the entities?
An example would be the aspnet_Users entity which is never corrected to become its singular form of aspnet_User. I'm tiring of manually correcting this name in not only the entity itself, but the 10 or 12 navigation properties involving this entity.
Any suggestions?
Try Entity Developer. We provide flexible Naming Rules:
(source: devart.com)
I've just performed a test, and aspnet_users table was named AspnetUser in the conceptual model.

MS CRM 4 - Custom entity with "regardingobjectid" functionality

I've made a custom entity that will work as an data modification audit (any entity modified will trigger creating an instance of this entity). So far I have the plugin working fine (tracking old and new versions of properties changed).
I'd like to also keep track of what entity this is related to. At first I added a N:1 from DataHistory to Task (eg.) and I can indeed link back to the original task (via a "new_tasksid" attribute I added to DataHistory).
The problem is every entity I want to log will need a separate attribute id (and an additional entry in the form!)
Looking at how phone, task, etc utilize a "regardingobjectid", this is what I should do. Unfortunately, when I try to add a "dataobjectid" and map it to eg Task and PhoneCall, it complains (on the second save), that the reference needs to be unique. How does the CRM get around this and can I emulate it?
You could create your generic "dataobjectid" field, but make it a text field and store the guid of the object there. You would lose the native grids for looking at the audit records, and you wouldn't be able to join these entities through advanced find, fetch or query expressions, but if that's not important, then you can whip up an ASPX page that displays the audit logs for that record in whatever format you choose and avoid making new relationships for every entity you want to audit.
CRM has a special lookup type that can lookup to many entity types. That functionality isn't available to us customizers, unfortunately. Your best bet is to add each relationship that could be regarding and hide the lookups that aren't in use for this particular entity.

Resources