Scenario
A well-known taco establishment wants to build a Django app with models Combo, ComboItem, Ingredient, and Order.
Headquarters wants to create various combos with included items and layout the original item ingredients and price.
Each franchise can then select which combos they will sell on their menu and is allowed to adjust the price and ingredients of combo items for their store.
When an order comes in, the combo and item details should show on a log and should not change in the future if HQ renames a combo or the franchise changes the price/ingredients.
Use Case
HQ creates the "Hot Taco Combo". It has three related combo items
a taco (price: $.99, ingredients: shell, beef, cheese, hot sauce)
churro-spirals (price: $.79)
drink (price: $1.29)
The NY franchise adds the Hot Taco Combo to their menu. They adjust the price of the taco to $1.49 and add lettuce to the taco.
A customer orders the combo with no cheese on the taco.
HQ changes the name of the combo to Fiery Taco Combo - NY's combo name updates but the taco remains the same custom price and still includes lettuce.
A manager at the NY franchise views all orders and see's one order for Hot Taco Combo and the taco ingredients are only shell, meat, and lettuce.
Issue
I'm struggling to decide the best way to handle this because a Combo is basically the same object at all three levels, but its related ComboItem objects can be different. HQ should be able to update Combo attributes like the name and it would update all franchise combo names, but the combo item customizations should remain. Additionally, combo details and customizations at the point of sale should never change once recorded, for accurate order records.
Originally I thought to have an AbstractBaseClass for each of the related models and objects that inherit from them at each business level, but that structure feels redundant and difficult to maintain.
Then I thought to use GenericForeignKey to relate the Combo to either HQ, Franchise, or an Order and duplicate objects where necessary as they move down the levels. This feels weird and error prone.
Has anyone dealt with a case like this or have any recommendations? Is it just a matter of being a complex problem and needing a complex solution or is there a simple approach I'm missing? Thank you in advance.
It sounds like rather than abstract base classes, you're looking to use multi-table inheritance: https://docs.djangoproject.com/en/1.8/topics/db/models/#multi-table-inheritance
I'd recommend reading through this whole section of the docs to see what your options are for inheritance styles: https://docs.djangoproject.com/en/1.8/topics/db/models/#model-inheritance
Related
I need some help getting past a road block I've come across in creating my application in APEX.
This application will be to track financial disbursements from a company. It will utilize a one to many relationship. One associate to many different transaction details.
Using Quick SQL in APEX 19.2 I have created a couple tables. DISB and DISB_DTLS
DISB
Assignor vc
Processor vc
RCVD_DA date
PROC_DA date
ACT_NO number
APPROVER vc
STATUS vc
NOTES vc
DISB_DTLS
AMT number
etc
etc...
The problem I'm having is that I want to have the primary table DISB be for the associate. Hence "One Associate to Many Disbursements. However, we have so many details that it would make the interactive grid APEX uses way to big and squished when doing a Master Detail form. Yet the only way to modify two tables or a view would be a master detail form. That's why I put some disbursement info in the primary table DISB and not the DTLS table.
I know there are some creative applications out there, and need some help discovering what I can do in regards to updating multiple tables from one form, if possible. Or alternatives. I want to make this process easy for the associates. This was all in one spreadsheet at one point.
Thanks,
Joe
I recommend you don't compromise Database design over the UI.
What you can do in this case is filter segmentation.
Complete your Master-Detail as initially thought.
Some detail columns can be logically grouped so I would put some filters somewhere on the page which the users selects a Logical group of columns to be displayed. That way you hide/show the columns to ensure they fit on the screen. Think of Filters as radio buttons or even checkboxes, let the user choose what shows on the screen.
In my model Person can have more than one partner, so the ManyToMany Model is the only answer (this has to be ManyToMany for other reasons, so please don't think about changing it).
If I use default widget i got a list of all persons with selected one, two maybe three persons (which are partners of Person).
It would be ok, if the Person list is about 10-100 - and it works on test database. But my prod database has 10.000 persons or more, so the ModelMultipleChoice widget would be filled with 10.000 records, and finding the correct partner will last ages, and memory usage isn't trivial.
I need only to see names of partners with possibility to unset it from person, and some possibility to add new just typing name. The best solution is to show listbox with filtered names after typing three or four first letters, but any solution would be great.
With forms it would be easier, but I need it in admin, so I'd like to use django admin standards.
Considering scenario of an Inventory Management System. Inventory has many types of items, each with own table and columns. One, two or Twelve tables are not sufficient to describe the plethora of the TYPES of items as they are extremely varying. e.g. some attributes of a family of items like BIKES do not have the same attributes of CARS. It is tedious for developer to take into account the thousands of the TYPES of items and incorporate them into each model manually.
Is there a way for users to generate models themselves? thereby generating own SQL tables etc... Is there another approach to this problem? (Maybe using Semantic Web Technologies)
Coming from Spring Framework, I am fairly new to RoR development.
Thanks in Advance.
I'm not an expert, but you could do it with regular, pre-defined models.
Item_Type
Item_Attribute
Item
Item_Type would have a name variable (not unique), and perhaps any other common attributes you'd want. It would then have a has_many Item_Attributes relationship, whereas Item_Attribute belongs_to Item_Type.
So I'd make a view that allows the user to add new Item_Types and then define Item_Attributes for those item types.
Then you could have the actual Item model, each instance of which is the existence of an Item_Type in the inventory. Item belongs to Item_Type, and Item_Type has_many Items, and Item cannot have a null Item_Type.
So a user creates a new Item_Type with the name "BIKE", then adds several Item_Attributes to it, such as "Mountain" and "Red". Then the user can create a new Item that has a relationship to the "BIKE" Item_Type.
If they wanted to add a blue mountain bike instead of a red one, they would need to go through the process again, adding another Item_Type of "BIKE" except adding "Blue" as an attribute for the new instance of Item_Type's Item_Attributes.
The request
I want to add Members to their department in our Company, but our company has more offices and each office its own departments, so we need to organize that first and then try to assign each Member to its department so that they only have permissions to access their own department.
Departments overview as Umbraco Content:
Root Node
-Office 1
-- Department1.1
-- Department1.2
-Office 2
-- Department 2.1
-Office 3
-- Department 3.1
-- Department 3.2
-- Department 3.3
Now, if I add a User, I want one property to select the office and another to select the department.
Possible solutions
Checking here and there, I've seen I can make the Office property using the UltimatePicker type in Umbraco creating a custom data-type linked to a parent node and then a property inside my MemberType. That will display the offices under "Root Node" and link the member to one of them.
Now, to make the department property I've seen there could be some way using a custom manually-coded property, adding a usercontrol and using it to display the office children dynamically (I've not tried it yet, I'm theorizing).
But I am worried that the second property will be dependent on the first one, and when I've tried to create my custom property implementing umbraco.editorControls.userControlGrapper.IUsercontrolDataEditor in my usercontrol it only allows me to save one value, not two of them. Which has sense as this is supposed to be A property, and not a bunch of them.
My question
Now, what's the best way to have those 2 custom properties and also make sure that in case I change the office the department will be also refreshed?
Best crazy idea at the moment
Up to this moment, I can only imagine creating 2 usercontrols, one for each property, and manually clean the department each time the office is updated, though I don't know if this is possible (Can I really get departments dynamically? Can I clean the dep. property FROM office property usercontrol?) and I would prefer to have them together as to simplify the codes.
If the relationship is key and you need to prevent a user from accidentally choosing a department that doesn't belong to an office, then you could create a single usercontrol that contains two drop-down menus. The first menu displays the offices and the second is only populated (preferably by an ajax call) once an office selection has been made.
The code for retrieving the offices and departments would be relatively straightforward using the umbraco api.
The usercontrol could then save the id's of each to xml or a comma delimited list.
Alternatively, you could just allow the user to select a department and the office is implied by the choice of department. You could use the uComponent's multi-nodepicker and filter the node selection to only the Department doc type. The overhead then is in the UI code where you have to work out the Office from the Department.
To get around this, you could have a label property that simply stores the ID of the Department's Office. The Office ID could then be saved using an OnSave event handler.
In my content tree, I have a tree of content items which represent cities. For each of those I want to have logical connections to a set of... let's say... National Parks that are within 2 hours driving distance. So a city will have multiple parks... and each set will be different... but of course a park will also be associated with more than one city.
What kind of Item and field setup works well for this sort of situation? I will be creating a custom renderer for these items, so I'm mostly concerned with how this should look in Sitecore to maximize ease of use and performance.
I'm using Sitecore 6.2.
(cross-posting from SDN, please forgive me... but I want to encourage more Sitecore community here on StackOverflow)
For this kind of relationship you'll need the following structure:
Home
Cities
NY
London
Paris
Parks
Park1
Park2
Park3
The "City" template should have the Multilist type field called "Parks". The soulrce of this field should look to the root of Parks (Home > Parks). The same way the "Park" template has the Multilist field called "Cities". The source of this field should look to the root of Cities (Home > Cities).
In this way you'll be easily able to perform any kind of request.
Hope this helps.
If the connection has to be both ways one way you could handle it is by adding some code to the save event.
Let's assume we have a City template with a field called "Related Parks", and a Park template with a "Related Cities" field.
Say we save a City item with two parks in the "Related Parks" field. On the save event we could retrieve the two parks and insert the current city being saved into the "Related Cities" field on those parks.
I am not necessarily saying this is the best way to go about it, just another option.
Are you going to be doing any lookups from park to city? For instance, would you need to say "find all the cities that are associated with a given park"? Or will it just be "find all the parks that are associated with a given city"? If you need to do the lookups in both directions, things get a little trickier and I would probably recommend using a search index. However, if your lookup is only in one direction, you could just use a treelist field to make associations from one item to many others.
From your description I'm not entirely sure if you actually need to use that many-to-many relationship, or if a one-to-many path is all you need?