[
https://issues.apache.org/jira/browse/OFBIZ-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569379#action_12569379
]
Valentina Sirkova commented on OFBIZ-1590:
------------------------------------------
Hans,
First of all, thanks for caring for the entities. I have 2 questions and two
comments. Here are the questions(I asked it a lot of times but never got an
answer. I hope this time you will answer):
1. Why do you extend the Workeffort entity? I guess it is the easier way to go
as the current OFBiz implementation supports it but this is not the BOOK-BASED
approach, but a big FIX!
2. While we are at this stage of development why don`t we stop for a while and
think what is BEST for the PROJECT and even if necessary IMPROVE the current
implementation with the BOOK`s one?
Here is short comparison of the entities involved in current OFBiz reservation
implementation and the BOOK`s proposal:
Current OFBiz entities:
(1)OrderHeader - (2)OrderItem - (3)WorkOrderItemFullFillment - (4)WorkEffort -
(5)TechDataCalendar - (6)TechDataExcDay -
((7) TechDataCalWeek)
- entity number (3) is of no real use! It is just a connection to the
Workeffort.
- entities number (5),(6),(7) keep the same information as the workeffort.
BOOK`s entities: (This is based on my comprehention of Reservation and
ReservationItem from the book. I believe their
logical model in our OFBiz db are OrderHeader and OrderItem. Please correct me
if I am wrong!)
(1)OrderHeader(Reservation) - (2)OrderItem(ReservationItem)
Isn`t the book`s way better?
> Introduction of new reservation entities
> ----------------------------------------
>
> Key: OFBIZ-1590
> URL: https://issues.apache.org/jira/browse/OFBIZ-1590
> Project: OFBiz
> Issue Type: Improvement
> Components: order
> Affects Versions: SVN trunk
> Reporter: Valentina Sirkova
> Attachments: accomEntity.patch, accomProgram.patch,
> spot_class_map_entities.patch, spot_class_map_entities.patch
>
>
> I propose the introduction of the following entities: AccommodationClass,
> AccommodationSpot,AccommodationMap. Their design is based on the book "The
> data model resource book".
> - AccommodationClass could define classes for hotels, cars, planes etc. I
> have added one more field here parentAccClass, as I thought it could be
> valuable for building more complicated hierarchies.
> - AccommodationMap is used to say how many spaces a class has. I have
> extended it further with a field overbooked, which could store the
> overbooking data for each class. E.g if we have that field we might know how
> many rooms of class "deluxe" could be overbooked. The primary key of
> AccommodationMap in the book includes the "NrOfSpaces" field but I did not
> add it in the patch as I am not sure of its exact purpose.
> - AccommodationSpot defines the specific seat,room etc of a given class. It
> is very powerful entity as it let us define the seat as a spot simply. This
> is very useful for planes and buses for example as we have the chance to
> define all the seats as spots and are not required to make them fas. I have
> modified the type of the field "accomNumber" to be of type short-varchar as
> plane seats for example are mixture of letters and numbers(The book models it
> of type numeric). The fk fields include the "nrOfSpaces" field in the book
> which I have not included in my patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
