I am bit confused between 'o' and '-->' used in Model file, For example :
asset Field identified by assetId {
o String assetId
o Customer owner
--> Customer custId
}
participant Customer identified by customerId {
o String customerId
}
what is difference between "o Customer owner" and "--> Customer custId"?
The o indicates that this is an owned property of a class. Aka a "field". That means that when the instance of the class is removed, so are all its properties.
The --> indicates that this is a relationship to another addressable resource. Aka a pointer or primary/foreign key entity relationship.
In your example, your asset Field has a property or type Customer called owner. When instances of Field are deleted the instances of Customer that they are storing in the owner property are also deleted.
The Field asset also has a relationship to a Customer instance stored in a property called custId. Deleting an instance of Field will not delete the instance of Customer that is being pointed to by the relationship.
Composer relationships are essentially typed-pointers. They are a fully-qualified type name of the resource that is being pointed to, as well as the identified of the instance that is being pointed to.
In Composer relationships do not cascade-delete, and there is no referential integrity checking for relationships. It is up to the application to check whether the resource that is at the end of a relationship exists or not, and to respond appropriately.
Note that in the future we may prevent using o with assets and participants. It really doesn't make much sense and is confusing for people that expect to find them in their respective registries. For assets and participants people should use -->.
Related
I'm in need of some advice on something I haven't run across before, and while it is a necessary component of a friend's project, I am willing to be flexible in how I should go about it.
In their little museum, they have a staffing and document problem. For several sets of donor types, there are a variety of donor document requirements and what I am trying to do is have the donor type on the donor class reference to many on another table which lays out the required documents of that donor type and what type of required they are (either optional, but recommended or straight up required).
At the moment these are my donor model fields:
id
lastName
firstName
donorType
docStatus
And the relationship to the donorRequiredDocs model is:
public function donorRequiredDocs(){
return $this->hasMany('App\donorRequiredDocs', 'donorTypeID', 'donorType');
}
My donorRequiredDocs table is setup as such:
id
donorTypeID
requireType (optional, required)
docType (letter, agreement, etc - but in an INT which references another table)
Now say I have this example:
I am a donor, and my donorType is 1, and 1's are required to have the following documents:
Agreement
Letter of Approval
Notary Required SEM
and are recommended but not required to have:
Photograph of Donation
Statement of Account
And I go to donate an object to the museum, after they select my name and record for the new donation which would use my donor table id to pull up the model information they have on me. I want the the donation record docStatus to remain NULL or 0 until at the very least, the donation record has a relationship with one of each of the three above document types before it can be set to 1.
In this case the donation model is setup as such:
- id
- title
- donorID
public function documents(){
return $this->hasMany('App\donationAttachment', 'donation_id', 'id');
}
And the donationAttachment model is setup as such:
id
title
docType (which uses the same numbering system as the donorRequiredDocs table field reference)
donation_id
created_at
updated_at
In the end, besides automatically changing the status once the project determines that the donation has at least one of each of the required documents, I'd like to print it out on the blade until all requirements have been met.
If there is something I missed, I'm happy to post it, I'm just not sure about how to go about this and would appreciate any and all help. Thanks in advance.
I have been creating a model where one of my assets have a reference to a specific participant.
When I retrieve my asset using the composer-client API I would like to retrieve the details of the participant being referenced.
In the CTO language document I saw this sentence:
"Relationships must be resolved to retrieve an instance of the object being referenced. The act of resolution may result in null, if the object no longer exists or the information in the relationship is invalid." but it does not describe how to do it.
Can someone please let me know what is the best way to resolve a relationship so that I can retrieve the instance of the object (in this case a participant) that I am pointing to?
You can resolve relationships a couple of ways
Lets say we have an asset Widget that is defined as:
namespace SO
participant Person identified by email {
o String email
}
asset Widget identified by assetId {
o String email
--> Person owner
}
Once you have a Widget asset, you can call Widget.owner.getFullyQualifiedType() which returns the name of the participant registry the owner is in. Then call Widget.owner.getIdentifier() to get the id of the owner in the PersonRegistry, then call PersonRegistry.get(identifier) to get the owner participant
When getting the Widget from the WidgetRegistry, you can call WidgetRegistry.resolve(identifier) to resolve all relationships
I have three models, Employee, Assignment, and Store.
Employees have many Stores through Assignments, and Stores have many Employees through Assignments.
(Assignments link Employee and Store together via foriegn keys)
Employees can only have one current assignment to a store.
What I'm trying to do in the Employee's index view is to display the employee's currently assigned store name (name is a field in the Store model).
How would I do this?
Assuming your relations are set up in the usual way, use includes to eager-load the associated records:
#employees = Employee.includes( :stores => :employees ).all
Then in your view you'll have access to #employees.stores[n].name (.stores is a collection because you said Employee has_many :stores, ...).
What's the best way to handle this scenario?
I have a customer Model(Table) contains contact info for customers
I have Prospect Model(Table) contains contact info for store visitors that aren't customers
I have an Opportunity Model (Table) when either a customer or Prospect visits the store.
In my view I want to generate a new oppportunity. An opportunity can only contain either 1 customer association or 1 prospect association but not both.
In my opportunity model I currently have both the customer and prospect as nullable foreign Id's and and navigation properties. I also have an ICollection<> for Customers and Prospects on the opportunity model.
Is this the right way to do handle a conditional association?
When it comes to the view, I'm stuck on how would I make the customer or prospect association?
I am a computer science student, and this is my understanding on DB relationships:
Since you have two types of "People" - Customer - and Prospect - you could potentially have a table called "Person". In the Person table any common data among both entities would be stored (FirstName, LastName, Address1, Address2, City, State, Zip, etc...).
To indicate that a Person is a Prospect, you would have a Prospect table, which would have a PersonId to link to the person table. You can store more specific attributes about a prospect in this table.
The same would go for a Customer - you would have a Customer table - that would have a PersonId column to link to the Person table, and any specific attributes for the Customer entity.
Now you have a database in which you can derive other entities ... say an Employee entity > you have your base Person Entity to start from. And your Employee table would link back to it, and also have other custom columns for employee specific data.
Does that make sense?
Or maybe I'm going about this all wrong :). Please correct me if I am wrong as I am still a student.
I think you are stuck because you now have two fields on an "Opportunity" record (Customer OR Prospect), one of which MUST be null. With the model I proposed, your Opportunity would link to a Person, in which you can define custom business rules restricting say... an Employee Opportunity (which actually might not be a bad idea).
For the referenced Person in your Opportunity model, it would not be an ICollection (since you specifically said that an opportunity can have ONLY one person). It would simply be a single class such as:
private virtual Person Person { get; set; }
EDIT: If you don't want to restructure your entire database, you could just have a dropdown that asks what type of Opportunity this is (Customer, or Prospect). Based on the selection, you would add a foreign key in your Opportunity table to link to your [Customer or Prospect].
Suppose I have an automatically-generated Employee class based on the Employees table in my database.
Now suppose that I want to pass employee data to a ShowAges method that will print out name & age for a list of employees. I'll retrieve the data for a given set of employees via a linq query, which will return me a set of Employee instances. I can then pass the Employee instances to the ShowAges method, which can access the Name & Age fields to get the data it needs.
However, because my Employees table has relationships with various other tables in my database, my Employee class also has a Department field, a Manager field, etc. that provide access to related records in those other tables. If the ShowAges method were to invoke any of those methods, this would cause lots more data to be fetched from the database, on-demand.
I want to be sure that the ShowAges method only uses the data I have already fetched for it, but I really don't want to have to go to the trouble of defining a new class which replicates the Employee class but has fewer methods. (In my real-world scenario, the class would have to be considerably more complex than the Employee class described here; it would have several 'joined' classes that do need to be populated, and others that don't).
Is there a way to 'switch off' or 'disconnect' the Employees instances so that an attempt to access any property or related object that's not already populated will raise an exception?
If not, then I assume that since this must be a common requirement, there might be an already-established pattern for doing this sort of thing?
maybe not the answer you're looking for,but how about projecting the results of your query into a more light-weight POCO, eg:
var employeePOCOs = from e in l2sEmployees
select new EmployeePOCO
{
Id = e.Id,
Name = e.FirstName + " " + e.LastName
};
where EmployeePOCO is a predefined class
would that help? I've used this when returning Entity Framework objects back through an AJAX call where the output was going to JSON, and it seemed to do the trick.
One way to do this is to 'detach' the entity from its database context. Take a look at an answer I gave to a similar question. It shows you a couple ways of detaching entities.