I'm having a difficult time trying to figure out how to model a certain scenario as a UML design class diagram.
Suppose I have the following situation:
I have an employee called X who is the CEO of the company.
A, B and C reports to X and U,V reports to A.
According to me, there should be an Interface called IEmployee which should have employee's name, designation and empNo.
Employee class should implement this IEmployee.
Manager class should implement Employee.
interface IEmployee
{
}
class Employee: IEmployee
{
}
class Manager: Employee
{
}
is there any more efficient way to do this?
No idea what you think SOLID principals should be, but your diagram would look like this:
Employee implements (realizes) IEmployee and Manager specializes Employee.
Related
Lets say I want to track employees working on projects.
Project 2015
- Employee A
Employee A now changes his healthcare-provider,
address and completes his bachelor degree.
Project 2018
- Employee A
For Project 2018 the Employee A details are up to date. But if I look
back at project 2015 the Employee A details are now newer than the Project itself. For example now it looks like Employee A had a bachelors degree when working at Project 2015, which is incorrect.
What I need is like an instance of Employee A frozen in time/time capsule/snapshot/copy when saving him to a Project. While still being able to update the "live" version of the employee.
There are other models where I will run into the same problem. It really boggles my mind, because it's so counterintuitive for database-thinking. Is there a right/correct way to handle this. Is there maybe a Django revision? solution? Thank You!
The project django-simple-history is very useful and you can have snapshots of your objects.
I had similiar challenges and we worked it out by doing a pattern that would rougly translate to this domain as:
class EmployeeProfile(Model):
class Meta:
abstract = True
common_field1 = CharField()
common_field2 = CharField()
common_field3 = CharField()
def get_employee_profile_data(self):
return {
'common_field1': self.common_field1,
'common_field2': self.common_field2,
'common_field3': self.common_field3,
}
class Employee(EmployeeProfile):
specific_fields
class ProjectProfile(EmployeeProfile):
class Meta:
unique_together = ('project', 'employee')
project = ForeignKey(Project)
owner = ForeignKey(Employee) # Means that the Employee "owns" this profile
# A factory function
def create_project_profile(employee, project):
return ProjectProfile.objects.create(
project=project,
owner=employee,
**employee.get_employee_profile_data())
We tried to think with separation of concern in mind.
I this scenario I think the pattern fulfills the following:
A project have project specific profile which is owned by an Employee
An employee can only have one profile per project
It is possible to change the specific profile for a project without affecting the "live data"
It is possible to change an employee profile live data without affecting any project
Benefits are that database migrations will affect both Employee and the ProjectProfile and it should be simple to put get_employee_profile_data under unittest.
The owner reference will make sure it's easy to query for participants etc for projects.
Hope it can give some ideas...
I want to have a superclass that will be inherited by subclasses.
Let's say I want the superclass mother to be inherited by child.a and child.b.
So I make these classes
mother:
class mother(osv.osv):
_name = "mother"
mother()
child.a:
class child_a(osv.osv):
_name = "child.a"
_inherit = "mother"
child_a()
child.b:
class child_b(osv.osv):
_name = "child.b"
_inherit = "mother"
child_b()
now let's say I have a class a that have a many2one connection to mother
class a(osv.osv):
_name = "a"
_columns = {
'mother' : fields.many2one('mother', 'Mother'),
}
a()
Does mother field accept both class child.a and child.b. If yes how to code the create and write methods. If not how do I achieve this in any other way? (field accepting multiple subclasses)
No, a many2one referencing mother can't address records of class.aor class.b.
The inheritance method used for class.a and class.b actually copies the mother features. They create two new independent tables, copy of mother, containing independent data sets.
This means that the classes are not interchangeable in any way.
Records in child.a are not present in motherand vice-versa.
What you describe can be achieved with delegation inheritance - you can think that as class.x having a mother class "embedded" in it, through a special many2one relation.
This way, when you create a new class.x record, a new mother record is also implicitly created.
But this works one way: creating a new mother record does not create a class.x record.
An example of delegation inheritance in the core modules is res.users: a User "embeds" a Partner. When a new user is created, a new Partner is also created for it.
Many2one relations to Partners will also be able to reference the User embedded Partners. But many2one relations to Users will not be able to reference Partners that are not Users.
I need to know how to decide what is a resource and what is a sub resource. I just have some tables for which i need to make uri's. so lets say i have a student table and studentclass(which gives the name and probably some more details of the class that the student is enrolled in) table with (N:1).
I will make student a main resource and design uri like below
http://home/someapi/v1/student/1/
Following a rest approach for building uri
Qus 1: Which uri shown below do i have to make for accessing the studentclass
1.http://home/someapi/v1/studentclass?studentid=1 or
2.http://home/someapi/v1/student/1/studentclass
Do i have to consider studentclass as a separate resource..?
and
Qus 2: Suppose there is N:N relation between tables then how should the design of uri be?
I suggest to deal with two resources: student and class.
You can get a student using the following URI:
http://home/someapi/v1/students/1
Note the plural here, read this article if you want to learn why you should use plural: http://blog.apigee.com/detail/restful_api_design_plural_nouns_and_concrete_names/.
If a student can be enrolled in one class, it could be a property of this student, so you could return the following JSON document (for example):
{
"student": {
"id": 1,
"firstName": "John",
"lastName": "Doe",
"class": {
"id": 10,
"name": "Room Y"
}
}
}
You could get a specific class with the following URI:
http://home/someapi/v1/classes/10
You could get all students for a given class with this URI:
http://home/someapi/v1/classes/10/students
Now, if you have a N-N relation between students and classes, it would change my first proposal about the student representation in JSON. Actually, the class relation would become a collection of class resources, not an embedded property of a student, and you should use the following URI:
http://home/someapi/v1/students/1/classes
Meaning "retrieve all classes for student #1".
You can expose both class and student resources. No need to decide which one is the main one as they describe two different things. Having /students and /classes allows you to create students and classes, you can link them, etc.
Last thing, it's recommended to use query parameters (?foo=bar) for filtering purpose.
I think StudentClass (or simply 'Class') should be a different resource as Class can be shared amoung students. So this Uri would suit your need:
http:home/someapi/v1/studentclass?studentid=1
I am getting confused about managing entities in a relationship. According to the book PRO JPA2, relationship should be manually configured and assigned at both ends of the relationship.
Now, consider this relationship.
#Entity
public class Employee {
..
#ManyToOne(cascade=CascadeType.PERSIST)
private Department department;
..
}
#Entity
public class Department {
..
#OneToMany(mappedBy="department")
private Set<Employee> employees = new HashSet<Employee>();
public void addEmployee(Employee e){
getEmployees().add(e);
e.setDepartment(this);
}
}
I made a simple test case that involves this line of code to verify this.
Department dept1 = new Department();
dept1.setName("MARKETING");
Employee e1 = new Employee();
e1.setName("JOHN DOE");
e1.setDepartment(dept1); //[1]
//dept1.addEmployee(e1); //[2]
Consider Line [1]:
I thought this would not properly update the Employee table with the correct department ID but I checked Derby and it is able to properly execute the update.
Consider Line [2]:
This is the proper way according to the book.
Eclipselink/Derby/JPA2
If you do it like in line [1], the Employee 'e1' will be stored in database with the FK ok, but... If you get Department dept1 and invoke getEmployees(); Employee 'e1' will not be in this list. Even if you make a new query to get that deparment from database again; it will not have Employee 'e1' (at least not until you reploy the application). That is why you should always do it in way [2].
When I started working with JPA2 I didn't know this; and was persisting entities like in [1]. I almost went crazy trying to determine why the recently persisted entities were not read by JPA, but were actually stored in the DB.
I would like to know if there is a way to disable automatic loading of child records in nHibernate ( for one:many relationships ).
We can easily switch off lazy loading on properties but what I want is to disable any kind of automatic loading ( lazy and non lazy both ). I only want to load data via query ( i.e. HQL or Criteria )
I would still like to define the relationship between parent child records in the mapping file to facilitate HQL and be able to join parent child entities, but I do not want the child records to be loaded as part of the parent record unless a query on the parent record
explicitly states that ( via eager fetch, etc ).
Example:
Fetching Department record from the database should not fetch all employee records from the database because it may never be needed.
One option here is to set the Employees collection on Department as lazy load. The problem with this approach is that once the object is given to the calling API it can 'touch' the lazy load property and that will fetch the entire list from the db.
I tried to use 'evict' - to disconnect the object but it does not seem to be working at all times and does not do a deep evict on the object.
Plus it abstracts the lazy loaded property type with a proxy class that plays havoc later in the code where we are trying to operate on the object via reflection and it encounters unexpended type on the object.
I am a beginner to nHibernate, any pointers or help would be of great help.
Given your request, you could simply not map from Department to Employees, nor have an Employees property on your department. This would mean you always have to make a database hit to find the employees of a database.
Aplogies if these code examples don't work out of the box, I'm not near a compiler at the moment
So, your department class might look like:
public class Department
{
public int Id { get; protected set; }
public string Name { get; set; }
/* Equality and GetHashCode here */
}
and your Employee would look like:
public class Employee
{
public int Id { get; protected set; }
public Name Name { get; set; }
public Department Department { get; set; }
/* Equality and GetHashCode here */
}
Any time you wanted to find Employees for a department, you've have to call:
/*...*/
session.CreateCriteria(typeof(Employee))
.Add(Restrictions.Eq("Department", department)
.List<Employee>();
Simply because your spec says "Departments have many Employees", doesn't mean you have to map it as a bi-directional association. If you can keep your associated uni-directional, you can really get your data-access to fly too.
Google "Domain Driven Design" Aggregate, or see Page 125 of Eric Evan's book on Domain Driven Design for more information
You can have the lazy attribute on the collection. In your example, Department has n employees, if lazy is enabled, the employees will not be loaded by default when you load a department : http://www.nhforge.org/doc/nh/en/#collections-lazy
You can have queries that explicitly load department AND employees together. It's the "fetch" option : http://www.nhforge.org/doc/nh/en/#performance-fetching-lazy