I am looking into the example use cases from OptaPlanner. And I could not find any similar example which can solve multiple planning variables in one planning entity. For example, in nurse rostering, each ShiftAssignment(PlanningEntity) for one shift might require multiple assigned Employee(PlanningVariables). In this case, how can we make use of planner and write rules?
Instead of making the OneToMany side a planning variable, make the ManyToOne side a planning variable. If you have a ManyToMany side, introduce a class between (like in relational database design) and acts as a ManyToOne-OneToMany.
In the nurse rostering example, an example can need 4 nurses on the Shift at ShiftDate 1-JAN for ShiftType Early. In that case, Shift has requiredEmployeeSize 4, and 4 ShiftAssignments are created for that single Shift, each with a different indexInShift. That way, the ShiftAssignment has a planning variable Employee which is a ManyToOne relationship, (even though between Shift and Employee there's a ManyToMany relationship).
Related
I want to extend the timetable example of the quarkus guide with the entity student. Each student grades all courses (eg. 1-6, more is better). Each student can visit all courses. I am looking for a student - course - allocation, so that the global sum of grades is maximal.
Can I do this with only 1 PlanningEntity or must I have 2?
Is there a trick to add a PlanningVariable List<Student> to Lesson?
I 'd argue this is a different planning problem, with a different Solver configuration (so a different #PlanningSolution and #PlanningEntity class) but which can reuse problem fact classes (Room, Timeslot, etc).
In practice, I'd remove the #PlanningEntity annotation (and the #PlanningVariable annotations) from the Lesson class, because the lesson to room/timeslot assignments will be part of the input, not part of the planning optimization. I am not sure if you even need room/timeslot information at all.
We don't support lists of planning variable (#PlanningVariableCollection) yet and I doubt it would be a good fit here because the order of the students in the list doesn't matter. A set might, but we don't support that either yet. It is being worked on. In any case, there's a much simpler solution:
Create a planning entity StudentToCourseAssignment class. Follow the docs chapter 22 domain modeling guide to decide if the planning variable is on the student field xor the course field.
Also replace the TimeTable class accordingly.
I have a use case of scheduling a person to some work for some time range. Eg. A service for assigning a person A to work for time range X to Z in location C.
The only constraint it has, is one person cannot work on 2 things at same time. Eg. if person A is assigned to work in time 2019-07-21 to 2010-07-25, then person A cannot be assigned to any other work in that time. Eg. Person A for time range 2019-07-23 to 2019-07-27 should not be possible.
I am trying to make a service for it using domain driven design which would assign a person to some work. The entity I thought would be something like:
class Assignment {
PersonId,
startTime,
endTime,
location
}
Now, I wanted to make sure that if I found a entry in my database for Person A in some time range, then the call to create an entry for Person A in time range that is overlapping with the existing ones should fail.
Since, I am using CQRS model with DDD, so I don't want to make a query to my database asking for all the assignments for that person. This may not always be recent data because of eventual consistency in CQRS model.
I know in my primary key, PersonId would be there but I am not sure how can I use start and end time in it.
Any suggestions what I can do to achieve my goal for this? Is doing DDD and CQRS not a good idea in this? Or there is a better way to model this entity so that I can achieve my goal.
Since, I am using CQRS model with DDD, so I don't want to make a query to my database asking for all the assignments for that person.
CQRS is just the separation between the read and write (commands and queries). When executing commands, you can query the write model.
If you have the assignments as a value object of the Person aggregate, checking if there is more than 2 assignments at the same time is easy. And if the assignments should be a separate aggregate then the Person aggregate should keep reference of the assignments.
I am modeling a new database and I have a problem to keep my db scheme generic in order to make it able to be updated in the future.
I have drawn a simple scheme which reflects the actual problem, let's say that I have an employee table which has all the common info from all employees. In addition, there are one table per possible assignment which all needs an employee with its custom columns. The business logic allows an employee to have different assignments.
What is the best way to bind each pk of different assignment tables into another table (in this case the Notification table)?
I'm reading Pro JPA 2. The book talks begins by talking about ORM in the first few pages.
It talks about mapping a single Java class named Employee with the following instance variables - id,name,startDate, salary.
It then goes on to the issue of how this class can be represented in a relational database and suggests the following scheme.
table A: emp
id - primary key
startDate
table B: emp_sal
id - primary key in this table, which is also a foreign key referencing the 'id' column in table A.
It thus seems to suggest that persisting an Employee instance to the database would require operations on two(multiple) tables.
Should the Employee class have an instance variable 'salary' in the first place?
I think it should possibly belong to a separate class (Class salary maybe?) representing salary and thus the example doesn't seem very intuitive.
What am I missing here?
First, the author explains that there are multiples ways to represent a class in a database: sometimes the mapping of a class to a table is straightforward, sometimes you don't have a direct correspondence between attributes and columns, sometimes a single class is represented by multiples tables:
In scenario (C), the EMP table has
been split so that the salary
information is stored in a separate
EMP_SAL table. This allows the
database administrator to restrict
SELECT access on salary information to
those users who genuinely require it.
With such a mapping, even a single
store operation for the Employee class
now requires inserts or updates to two
different tables.
So even storing the data from a single class in a database can be a challenging exercise.
Then, he describes how relationships are different. At the object level model, you traverse objects via their relations. At the relational model level, you use foreign keys and joins (sometimes via a join table that doesn't even exist at the object model level).
Inheritance is another "problem" and can be "simulated" in various ways at the relational model level: you can map an entire hierarchy into a single table, you can map each concrete class to its own table, you can map each class to its own table.
In other words, there is no direct and unique correspondence between an object model and a relational model. Both rely on different paradigms and the fit is not perfect. The difference between both is known as the impedance mismatch, which is something ORM have to deal with (allowing the mapping between an object model and the many possible representations in a relation model). And this is what the whole section you're reading is about. This is also what you missed :)
I've got a relatively complicated Core Data relationship structure and I'm trying to figure out how to set up value dependencies (or observations) across various to-many relationships. Let me start out with some basic info. I've got a classroom with students, assignments, and grades (students X assignments). For simplicity's sake, we don't really have to focus much on the assignments yet.
StudentObj <--->> ScoreObj <<---> AssignmentObj
Each ScoreObj has a to-one relation with the StudentObj and the AssignmentObj.
ScoreObj has real attributes for the numerical grade, the turnInDate, and notes.
AssignmentObj.scores is the set of Score objects for that assignment (N = all students).
AssignmentObj has real attributes for name, dueDate, curveFunction, gradeWeight, and maxPoints.
StudentObj.scores is the set of Score objects for that student (N = all assignments).
StudentObj also has real attributes like name, studentID, email, etc.
StudentObj has a transient (calculated, not stored) attribute called gradeTotal.
This last item, gradeTotal, is the real pickle. it calculates the student's overall semester grade using the scores (ScoreObj) from all their assignments, their associated assignment gradeWeights, curves, and maxPoints, and various other things.
This gradeTotal value is displayed in a table column, along with all the students and their individual assignment grades. Determining the value of gradeTotal is a relatively expensive operation, particularly with a large class, therefore I want to run it only when necessary. For simplicity's sake, I'm not storing that gradeTotal value in the core data model. I don't mind caching it somewhere, but I'm having a bitch of a time determining where and how to best update that cache.
I need to run that calculation for each student whenever any value changes that affects their gradeTotal. If this were a simple to-one relationship, I know I could use something like keyPathsForValuesAffectingGradeTotal ... but it's more like a many-to-one-to-many relationship. Does anyone know of an elegant (and KVC correct) solution? I guess I could tear through all those score and assignment objects and tell them to register their students as observers. But this seems like a blunt force approach.
I just postet a project on github which probably solves part of the problem with observings
http://github.com/mbrugger/CoreDataDependentProperties
A more detailed description of the project can be found there.
-(NSArray*) keyPathsForValuesAffecting would not have solved your problem as this only works across to-one relations
In addition you should not make the dependent attribute transient, as it makes your context "dirty" (unsaved changes) already after recalculating all values after loading