I have a database with some references,
An example is a Customer Table has the AddressId integer column, and an Address Table has the Idenity Auto Generated Id column. I reference these as primary the Address "Id" and the Customer "AddressId". Now when i generate the dbml file or use SqlMetal, i get in the Customer entity two properties for the reference, AddressId that is an int type, and Address as an Address type. This is confusing! can i get rid of this functionality?
And how could i turn off pluralize? Thank you.
You cannot turn off the 'feature' of generating both the foreign entity reference and the foreign key reference. L2S uses both of them in conjunction. So, you're going to have to get used to it. It was a little hard for me to get used to at first, but I then realized there are benefits to having both.
If I recall, SQLMetal has a command line option to turn off pluralizing, but cannot say for sure. I wrote my own code generator that generates my entities and data context object and I have it generate non-plural names.
Related
I’m pretty new to PowerApps and need to migrate an Access database over to PowerApps, first of all it’s tables to Dataverse. It’s a typical use case for a model-driven app, with many relationships between the tables. All Access tables had an autogenerated ID field as their primary key.
I transferred all tables via Excel ex/import to Dataverse. Before importing,I renamed all ID fields (columns) to ID_old and let Dataverse create its own, autogenerated ID field for each table.
What I want to achieve is to re-establish all relationships between the tables, where the foreign key points to the new primary key provided by Dataverse, as I want to avoid double keys. As a first step I created relationships between the ID_old field and the corresponding (old) foreign key field in the related table.
In good old Access, I’d now simply run an update query, filling the new (yet empty) foreign key field with the new ID of the related table. Finally, I would change the relationship to the new primary and foreign keys and then delete the old ID fields.
Where I got stuck is the update query. I searched the net and found a couple of options like UpdateIf / Patch functions or Power Query or Excel ex/import and some more. They all read pretty complicated and time intensive and I think I must have overseen a very simple solution for such a pretty common problem.
Is there someone out there who might point me in the right (and simple) direction? Thanks!
A more efficient approach would be to start with creating extra ID columns in Access. Generate your GUIDs and fix your foreign keys there. This can be done efficiently using a few SQL update statements.
When it comes to transferring your Access tables to Dataverse you just provide your Access shadow primary keys in the Create message.
I solved the issue as follows, which is pretty efficient in my perception. I”m assuming you have a auto-numbered ID field in every Access table, which you used for your relationships
Export your tables from Access to Excel.
Rename your ID fields to ID_old in all tables using Excel, as well as your foreign key fields to e.g. ForeignKey_old. This will make it easy to identify the fields later in Dataverse.
Import into Dataverse, using the Power Query tool. Important: Make sure, that you choose ID_old as additional primary key field in the last import step.
Re-create all relationships in Dataverse, using the Lookup datatype. This will create a new, yet empty column in your table.
Now use the “Edit in Excel” feature to open your table in Excel. You should get your prefix_foreignkey_old column with the old foreign keys displayed, as well as the reference to your related table, e.g. prefix_referencetable.prefix_id_old, which is still empty.
Now just copy the complete prefix_foreignkey_old column values into the prefix_referencetable.prefix_id_old column.
Import the changes and you’re done.
Hope this is helpful for some of you out there.
I've been messing with the Design view of my DBML class for hours now. I have one class, call it A, that has a 1 to many relationship with B, C, D, and E. In the generated code I can see that Class A has generated
private EntitySet<BB> _bb;
private EntitySet<CC> _cc;
private EntitySet<EE> _ee;
But it hasn't generated one for D. Finally for giggles I added a primary key to D; all the other classes had one except for D; and NOW it's generating a EntitySet _dd. But why is this? I don't need that table to have a specified primary key.
I assume you are using LINQ to SQL due to the .dbml files. LINQ to SQL (and Entity Framework to some degree) struggle with tables that do not contain primary keys. Specifically, the table needs a primary key to implement INotifyPropertyChanged (the interface that tracks changes for a specific identity... how can an entity be tracked if it does not have a primary key?). A good example of why this is needed can be found here.
https://social.msdn.microsoft.com/Forums/en-US/f3b216d2-fa06-49a1-a901-11702e80b38c/linq-to-sql-table-doesnt-have-primary-key?forum=linqtosql
As a follow up, is there a specific reason why the table does not have a primary key? Does it not represent a entity in your data model? If it is a "lookup" table perhaps you can wrap the functionality in a stored procedure and then call the stored procedure via LINQ to SQL.
I'm trying to understand entities, tables and foreign keys. I have the following:-
AnObject - I have identified this as an entity type.
ID (Primary Key)
Description
State
DependsOn
Creator
Now State has only two values it can be [Alive, Dead]. However it could possibly have another in the future. It can however only be one or the other but it will likely change between the two.
Question:
Should State be its own entity type? Would it be an entity type or
just a table? Should State have a foreign key to AnObject or vice
versa? EG
State
ID (PK)
Description
AnObject_ID (Foreign Key references AnObject)
Question: The DependsOn attribute of AnObject can have multiple values of other AnObject entity types. Obviously a field cannot have multiple values but I'm not sure how to model this?
The Creator attribute of AnObject also takes up a strict number of values [Fred, Jim, Dean]. Should I have an entity type (table) for a Creator with a foreign key to AnObject ID? So, A Creator can create, 0, 1, m AnObjects but AnObject can only have one creator?
Thanks,
State could just be an enum field, unless you need users to be able to add other State values via a user interface, in which case you could use a lookup table (one-to-many relationship) as you suggested. I don't know what database you're using, but here's some info on the enum type in MySQL: http://dev.mysql.com/doc/refman/5.6/en/enum.html.
If you use a lookup table, then AnObject should have a field called StateID that points to the desired row in the State table.
It sounds like DependsOn is a many-to-many relationship. For that you will need a join table, e.g.:
Table: Dependencies
Primary key (called a "composite key" because it's made up of more than one field):
AnObjectParentID
AnObjectChildID
I've assumed that the dependencies are needed for a parent-child relationship but if that's not the case you might want to name the table or fields differently.
You can add extra tables for enumeration values with a foreign key from AnObject to it. State will probably be best represented as a single field of type varchar not null. You can have the primary key for a table be a varchar field - they don't have to be int type.
This will constrain the values but allow you to use reasonable syntax to query the thing (i.e. WHERE state = 'Alive' (although in this case I think you're prematurely abstracting things - I'd keep it simple and just have a simple bool column IsDead).
DependsOn is a one-way attribute (you presumably can't have A depend on B and also B depend on A). The real issue here is how you're intending to query these items and how many of them there will be. If you want to pull out the whole chain of dependencies at once and the chain is long, you want to avoid doing hundreds of individual queries to do that. What is your use case?
The documentation for inaport states you can just map lookup fields and it will work out what types they are.
I am mapping from CRM 4 to CRM 2011 (using the CRM Connectors), however all my lookups fail with
A lookup value was mapped to account.{field name} but no target entity name was supplied and no default is available.
I have to fall back to adding a custom field, checking if their is a lookup id in the field, and then making a lookup value as per the documentation of guid::entityname using expressions which is painful.
Is this feature working for anyone else? Do i need to set up a child-parent relationship? I only ever add a map for the entity I'm working on.
Inaport will try to work out what the correct entity reference is and default it. For example, if the lookup is the foreign key in a child table, the entity reference will default to the parent.
There are some circumstances where a lookup may reference multiple entity types, and Inaport cannot infer the correct type. For example, and activity "regarding" lookup may reference 12 different entity types.
It could do a better job when a custom lookup is only referencing a single entity type, and a change request has been put into the system.
As you noted, when Inaport does not correctly infer the entity type you can force it by appending "::entityname" to the GUID you are mapping to the lookup field. This is discussed in more detail in the help.
HTH
Regards
David Evans
I'm using before and after insert triggers to generate ids (primary key) of the form "ID_NAME-000001" in several tables. At the moment, the value of the hibernate generator class of these pojos is assigned. A random string is assigned to the object to be persisted and when it's inserted by hibernate, the trigger assigns a correct id value.
The problem with this approach is that I'm unable to retrieve the persisted object because the id only exists in the database, not in the object I just saved.
I guess I need to create a custom generator class that could retrieve the id value assigned by the trigger. I've seen an example of this for oracle (https://forum.hibernate.org/viewtopic.php?f=1&t=973262) but I haven't been able to create something similar for MySQL. Any ideas?
Thanks,
update:
Seems that this is a common and, yet, not solved problem. I ended up creating a new column to serve as a unique key to use a select generator class.
Hope this won't spark a holy war for whether using surrogate key or not. But it's time to open the conversation here.
Another approach would be just, use the generated key as surrogate key and assign a new field for your trigger assigned id. The surrogate key is the primary key. You have the logically named key (such as the "ID_NAME-000001" in your example). So your database rows will have 2 keys, the primary key is surrogate key (could be UUID, GUID, running number).
Usually this approach is preferable, because it can adapt to new changes better.
Say, you have these row using surrogate key instead of using the generated id as natural key.
Surrogate key:
id: "2FE6E772-CDD7-4ACD-9506-04670D57AA7F", logical_id: "ID_NAME-000001", ...
Natural key:
id: "ID_NAME-000001", ...
When later a new requirement need the logical_id to be editable, auditable (was it changed, who changed it when) or transferable, having the logical_id as primary key will put you in trouble. Usually you cannot change your primary key. It's horribly disadvantage when you already have lots of data in your database and you have to migrate the data because of the new requirement.
With surrogate key solution, it'll be easy, you just need to add
id: "2FE6E772-CDD7-4ACD-9506-04670D57AA7F", logical_id: "ID_NAME-000001", valid: "F", ...
id: "0A33BF97-666A-494C-B37D-A3CE86D0A047", logical_id: "ID_NAME-000001", valid: "T", ...
MySQL doesn't support sequence (IMO autoincrement isn't comparable to sequence). It's different from Oracle/PostgreSQL's sequence. I guess that's the cause why it's difficult to port the solution from Oracle database to MySQL. PostgeSQL does.