Hi Hans and others, I will start from discussing Hans post and then comment and answer to the rest of the posts (they are a lot :) ).
On Mon, 2008-01-28 at 10:58 +0700, Hans Bakker wrote: > 1. on the accomodation spot it is perhaps better to use the > 'description' field instead of number, to be able to also say: "table in > the corner with the nice view"? It still can contain a number. Yes Hans, I agree here but maybe it will be even better if we still KEEP this field as it is designed to store accommodation number and not the description. Maybe we could simply add one more field for description. > 2. In the accomodation map i do not see the reason for the 'overbooked' > field, availability is better kept the the workeffort entity (search the > workeffort entity for the specific time and the specific accomodation > map/spot) and the number of spaces is available in the accomodation map. Well, I put overbooked field there as this entity`s purpose is to keep the general data for the class, so I thought its logical place is there. Also these 3 entities are part of "travel orders" from the book which do not involve the Workeffort entity at all. I know the CURRENT OFBiz implementation involves it in the reservation logic and therefore the easiest way is to put it there..but I am not sure if extending the workeffort entity is the real solution, it is probably sort of a FIX with our current logic. IMHO workeffort and techdata calendars should not be involved with reservations and NEW improved implementation of the reservations in OFBiz should be introduced based on the book-I can help with that. Actually there was discussion based on that which died http://www.nabble.com/Stop-using-techdata-calendar-to12220306.html#a12220306 > 3. should the fixed asset be part of the primaryKey of the accomodation > map? let me know why? Well, it makes sense to me why the book models it this way - I guess the reason for that is as all classes are related to some fas(hotels,restaurants etc) but I do not believe this should be a must for us! > 4. Should the class be a field in the map? isn't it more a specification > of the spot? YES, definately..there is no point of the map without the class... It should say how many places a class has in a given FIXEDASSET. I guess the question comes from the fact that these two entities are almost the same! Well, I was with this confusion for a while too. These two entities have really similar fields so for some time on I was using the map instead of the spot in my local copy and that is why I described to you the number of the seats etc in the map entity:) see here http://www.nabble.com/Re%3A-seats-tables-in-a-restaurant-% 28or-plane-or-cinema%29-p14891741.html Here is a quote from the book p370 (I guess I am answering David`s question here) "Because Transportation vehicles and hotels have AccommodationMaps to show what can be booked figure 8.3 each ReservationItem may be reserving an AccommodationSpot which would reserve a specific SEAT Number or Room number whihch would correspond to a spot that is available withiin the AccommodationMap for that type of accommodation" I guess this separation is logical. Map entity saying only the total number of spaces per class and spot entity - the actual spot(seat,room) within this class. Which means availability services would check the total capacity of the the room type in the map entity and then would reserve spots (real room numbers) from the spot entity. Well this could be achieved with one entity only - the spot entity. The cons of having one entity is it will be larger and this logical distinciton- map and the specific spot within that map will not be that intense. > 5. I did some adjustments to the field types. > > please let me know what you, and others think about this proposal. > > <entity entity-name="AccommodationClass" > package-name="org.ofbiz.order.reservations" > title="Accommodation Class"> > <field name="accommClassId" type="id-ne"></field> > <field name="parentAccommClassId" type="id"></field> > <field name="description" type="description"></field> > <prim-key field="accommClassId"/> > <relation type="one" fk-name="ACCOMM_CLASS_PAR" title="Parent" > rel-entity-name="AccommodationClass"> > <key-map field-name="parentAccommClassId" > rel-field-name="accommClassId"/> > </relation> > </entity> > > <entity entity-name="AccommodationSpot" > package-name="org.ofbiz.order.reservations" > title="Accommodation Spot"> > <field name="accommSpotId" type="id-ne"></field> > <field name="accommClassId" type="id"></field> > <field name="fixedAssetId" type="id"></field> > <field name="nrOfSpaces" type="numeric"></field> > <field name="description" type="description"></field> > <prim-key field="accommSpotId"/> > <relation type="one" fk-name="ACCOM_CLASS" > rel-entity-name="AccommodationClass"> > <key-map field-name="accommClassId"/> > </relation> > <relation type="one" fk-name="SPOT_FA" > rel-entity-name="FixedAsset"> > <key-map field-name="fixedAssetId"/> > </relation> > <relation type="one-nofk" fk-name="ACCOMM_MAP" > rel-entity-name="AccommodationMap"> > <key-map field-name="accommClassId"/> > <key-map field-name="fixedAssetId"/> > </relation> > </entity> (just a note here) The last relation to the Map entity..if you get rid of the class field in the map entity as you have showed in your post you cant use the last relation to AccommodationMap like this.Maybe something like this would be right: <relation type="one-nofk" fk-name="ACCOMM_MAP" rel-entity-name="AccommodationMap"> <key-map field-name="fixedAssetId"/> </relation> > <entity entity-name="AccommodationMap" > package-name="org.ofbiz.order.reservations" > title="Accommodation Map"> > <field name="accommMapId" type="id-ne"></field> > <field name="fixedAssetId" type="id"></field> > <field name="nrOfSpaces" type="numeric"></field> > <prim-key field="accommMapId"/> > <relation type="one" fk-name="ACMD_MAP_FA" > rel-entity-name="FixedAsset"> > <key-map field-name="fixedAssetId"/> > </relation> > </entity> I do not believe this is a good approach. > > Add 2 fields to WorkEffort and to the shoppingcart: > > <field name="accommMapId" type="id"/> > <field name="accommSpotId" type="id"/> IMHO, this way of thinking would lead to many more extentions to an entity which is probably more intented for manufacturing and workeffort usage and not for reservations. For example sooner or later we`ll need to add as David suggested ScheduledTransportation entities, also I believe we`ll need to add Ticket entitiy and maybe others which would relate to the ReservationItem directly. This`ll lead to further extentions to Workeffort. The book handles reservations thru Reservation and Reservation entities. In our OFBiz project this is neither the Workeffort nor any of the TechDataCalendars and I am not sure if complicating them further is a good way to go. I guess the better direction would be to rethink our current OFBiz implementation and improve it based on the book`s way. IMO, OrderItem is logically what is ReservationItem from the book and this is the entity which will have to be extended(but I need the comminity`s opinion on that). Of course this would mean we`ll have to reimplement our current OFBiz code. I have ideas how this could happen and what exactly should be changed. If the community is interested in this idea we could discuss it further and I could provide more detailed picture of that.
