In AX2009, how is it possible to find the table that is related to an InventTransType in the code?
For instance, InvnetTransType::Sales is related to the SalesTable, but how is it possible to get the table id or table name from SalesTable in the code?
I do not think this is possible, because there is no 1:1 relationship between the elements of the InventTransType enum and tables. At best there is a 1:n relationship (e.g. you could argue that InventTransType::Sales is related to table SalesLine just as well or even better as table SalesTable). Note also that the documentation on the enum says that it specifies "the module that generated the transaction".
It really depends on the question you ask and the data you want to retrieve. That said, here are some points you could research, maybe one of them fits your question/requirements. If all else fails, you can always write your one mapping method that takes an enum element and gives you the id of the table you think is appropriate for this element(standard AX does this in several cases to map other entities to the enum elements, see for example table InventDimSetup, method transType2FieldId).
cross references: check the cross references of the enum or of an enum element, that should give you an idea which table(s) are associated with which element
relations of table InventTrans: for some of the enum elements, you can find table relations in table InventTrans (but unfortunately not for all of them); ponus point is that by using reflection, you can analyze the relations and get the referenced table (which is probably as close to your requirement as it can get in standard AX)
Related
I can't believe this hasn't come up for other people, but I'm unable to find a solution.
Let's say I have two entity types, A and B with a one-to-many relationship. A has a collection of Bs.
The form for A has a CollectionType for the Bs, with a custom entry_type for B, allow_add and allow_delete set to true. When the form is created/populated/rendered, the Bs' fields are identified by their index in the collection. When the form is posted back, the fields are mapped back onto the B entities according to the index again.
What if the database in the mean time decided to return the Bs in a different order? Then the values get swapped around on the Bs! I can't have that, as other entities will reference the Bs and now they've changed their meaning!
Even if the database doesn't change the order, the same issue appears when a B is deleted: The fields get shifted through the Bs and a different one deleted! (Ok, I'm not a 100% certain this happens, as there's a gap then in the numbering of the posted fields.) I've found this similar question where it does happen when another one is created (Symfony CollectionType regards deletion+creation as a modification of an item), but that sort of drifted from the issue and there's no usable answer.
How do I make sure the form is updating the entities the user actually edited?
I already tried to render the Bs' IDs as a HiddenType, but then the form rightfully complains that the ID has no setter. It would probably force an ID on the wrong B anyways and Doctrine doesn't like that. I suppose I could add the Bs as unmapped and copy the values over to the correct objects manually, but that would defeat a good chunk of Symfony's form system.
I've used CollectionType before, but not for entities that are referenced elsewhere. I would then delete all of the previous entities and create the collection anew from the posted data. But I can't do that now, can I?
Since doctrine 2.1, it's possible to change how associations are indexed. This will allow you to use the id as the collection key (as the field has to be unique):
#OneToMany(targetEntity="B", mappedBy="A", indexBy="id")
You might also need to enable orphanRemoval so that the data is actually removed instead of the relation just set to null.
I am working on a web project where the user should be able to create custom types of merchandise containing any amount of properties of different types (numbers, text, etc). E.g: a box, which has name, price and physical dimensions, and a bottle, which has name, price, and volume.
What would be the best way to represent this in code and in the database?
My first idea was to create a basic template for a piece of merchandise, and dump all the custom data in a single field as stringified JSON. The downside is that this data couldn't be used for IQueryable search, filtering, sorting.
I can also think of creating a separate table, in which I'd store all the custom fields of all merchandise, and referencing them via relations. Wouldn't this, however, cause problems with scaling, as I will be essentially storing all custom properties everywhere in a single table.
Is in the best way to do it? There is no way to create new classes and database tables on the fly in .NET Core, of course, but what other options there are?
Thank you for your time,
I'm doing this in my current side project, and I've done it in the past as well. Basically, you will have a base Product table (or whatever you want to name it). Then you also have tables such as ProductAttributeType and ProductAttribute.
The base Product table would contain attributes common to all products, such as Name and Price.
ProductAttributeType
ProductAttributeTypeCode VARCHAR(10)
AttributeTypeName VARCHAR(50)
Where ProductAttributeTypeCode contains a short / abbreviated code for the attribute type (e.g. "BOOL"), and AttributeTypeName is a friendly name (e.g. "Boolean" or "Yes/No").
ProductAttribute
ProductId INT -- Foreign key to Product table
ProductAttributeTypeCode VARCHAR(10) -- Foreign key to ProductAttributeType table
AttributeName VARCHAR(100) -- The name of the product attribute (e.g. "Volume")
AttributeValue VARCHAR(MAX) -- Contains the actual value of the product attribute
Product has a one-to-many relationship with ProductAttribute.
This is the approach I've taken in the past, as well as in a current project, and it works pretty well. It appears to be a pretty common approach for solving this sort of problem. The only "downside" I can think of is that you need to make sure that the value in the ProductAttribute.AttributeValue column matches the appropriate type for ProductAttributeType(Code). If you design your code properly, and it's well thought out, it's really not so bad, in my opinion.
Can someone check my ERD, because I don't know whether I'm doing it correctly or not. I'm not sure about the difference between strong and weak entity, what I'm sure is that strong entity has their own primary key.
Other than that, is it correct i need to take Payment_ID as foreign key in my order table ? and what other attribute that i could have in my ORDER TABLE
Maybe some suggestion on what to add or improve on my ERD. Here i have a image for my ERD. Thank You
Entity Relationship Diagram
PAYMENT has an ORDER_ID and ORDER has a PAYMENT_ID. Having both fields is redundant, I would remove ORDER.PAYMENT_ID which would be a nullable field if customers don't pay immediately.
ORDER_DETAILS requires a PK, either a surrogate key ORDER_DETAIL_ID or the combination of ORDER_ID, ITEM_ID.
Can a PAYMENT use only one or more than one COUPON? The cardinality on the crow's foot line says more than one, but the PAYMENT.COUPON_ID field would allow only one. A nullable PAYMENT_ID in the COUPON table would be a better choice.
You have some doubtful minimum cardinalities. A CUSTOMER must place at least one ORDER? Ok, I can accept that. An EMPLOYEE must take at least one ORDER? So everyone in the company must take orders, and you're not going to record employees until they've taken an order? Also, every ITEM must be referenced in ORDER_DETAILS? Are you not going to want to record items on offer before they're ordered?
Finally, a note on terminology: your diagram is better called a table diagram, not an ERD. To be called an entity-relationship diagram, a diagram has to distinguish the concepts of the entity-relationship model. The style of diagram you used doesn't distinguish entity sets (i.e. ID fields) from value sets (non-ID fields) or entity relations (tables with single-field PK) from relationship relations (tables with composite PK, i.e. ORDER_DETAILS is a relationship relation).
I asked a related question previously on this forum. This question outlines the steps I have taken, different things I have tried and errors I have encountered. It might help someone.
Considering a mapping to a structure that involves a link table, it seems to me there is a quirk with Code First, Link Tables and TPH or perhaps just a lack of transparency.
I created a derived class with a [Table("")] attribute to map objects to the following sort of table structures:
(Case 1) Employees -> Attributes -> AttributeTypes
(Case 2) Employees -> EmployeeAttributeLink -> Attributes -> AttributeTypes
In the former case i achieved the results i wanted for TPH querying and saving. (I used data annotation attributes along with fluent api to map the derived classes to the correct discriminator id column).
However, in the second case I got this error:
'The entity types A and B cannot share table B because they are not in the same type hierarchy [OR] do not have a valid one to one foreign key relationship with matching primary keys between them. Need to have a 1-1 correspondence'
When I looked at the names of the tables that it was trying to map types to I could see it was confused. However I could not figure out what I was doing wrong as I had used the correct table mapping attribute above the inheriting classes (I didn't define all the sub types that could come from the discriminator - does that matter?).
I introduced some FK attributes trying to address the second part of the [OR] in the error message. This led me to new problems i.e. unable to determine principal/dependant... Then I tried to use the [InverseProperty] attributes... And then I started pulling my hair out.
Now, rolling back and removing the attributes, I decided not to rely on [Table("")] attribute and map the type to the table using the fluent api. This seems to work.
My question is: Why is it that the behaviour of the [Table("") ] attribute and the ToTable function on the fluent API behave differently? I would have thought they are interchangeable
Thanks
I am using EF 4.1 RC and CodeFirst/POCO to build my database by code.
Imagine having a many-to-many relationship like Teachers-Students (one teacher can have many students, and one student may have many teachers). Accordingly I have two POCOs: (1) Teacher and (2) Student.
When EF creates the corresponding tables you will end up with three tables: (1)Teachers, (2) Students and (3) an extra join table. The join table contains exactly two fields: a Teacher_ID and a Student_ID.
I was wondering if I had any chance to add an extra field to the join table, e.g. "Grade" (the grade a certain teacher gives a certain teacher)?
Currently I have no idea how to achieve this with only two POCOs.
So I guess all I can do is create a third POCO (for the join table) manually, am I right? That will certainly work, but then I am losing nice navigation properties like oneTeacher.Students.First(), etc. That is the main reason why I am still looking for another way.
That's correct, and does not only apply to Code-first. If you have extra fields in your joining table, you will have it mapped as an entity. And vice-versa, if you want an extra field in your joining table, you need to create a new entity and have zero-or-one-to many or one-to-many navigation properties to the Teacher and Student entities. In any case, you lose the comfort of accessing Teacher.Students and Student.Teachers and have to go via the intermediate entity.
Alternatively, you could think about modeling the DB structure differently and extracting the extra info into the Teacher or Student or a fourth entity. But that depends entirely on your scenario.
Yes, the join table cannot have a payload or you need to break it down to 2 one to many association which will result in creating a third entity to hold the PKs as well as the additional properties.
This is an idea I still haven't found time to try it out. Maybe you can keep your Student and Teacher classes as they are, and add a third POCO StudentGrade with properties Student, Teacher and Grade. Then you'll have to use the fluent API to make sure that both the many to many relation between Student and Teacher and the StudentGrade class map to the same table.
Hope that helps