Sigh, sometimes, i lose the will to live.
Richard, thank you for your reply, but really - it's best you save time and effort and not reply to my posts, honestly, unless you can help. In this case my impression is that you havent read the question and with respect have failed to grasp the nettle. I went to great lengths to articulate the scenario and you fail each time to understand - I'm interested in what others would do - I do not need training - I merely ask for other VIEWS Richard. look, Please save yourself frustration and reply to other posts on these forums more deserving of your time as this tends to be trend of yours.
We have a saying here
RTFM ... or rather in this case, RTFQ !
You asked what is the "pythonic" way to do this, and I answered that part: there is nothing in Python that is different from other object oriented languages. The documentation on Python classes is quite clear.
If you are expecting someone to do a complete design for you then I think you may be disappointed.
So two people have completely "failed to grasp the nettle", and you assume the problem MUST be that they're idiots, or that this site is "a joke".
The failure to communicate couldn't possibly be a problem with your question, could it?
Back away from the computer. Take several deep breaths. Go and do something relaxing for a while. Then come back without the attitude, and explain your question in more detail. If someone doesn't seem to understand, then don't fly off the handle; explain it in yet more detail. Keep elaborating until either they understand, or the solution jumps out at you.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
The problem here is that Pythonic refers to a using the language in such a way that it is clear, maintanable and concise. That's not really an aspect of how you break down the design of your architecture; rather it's a case of, when you have your architectural domain designed, how do you use the language following Pythonic principles and, more importantly, how do you structure your code so that others can use yours in a Pythonic way. I really do think you are conflating two separate problems in this question.
I want to allow the user to create their own lookup values that would be populated in a combo box. For example, an account's Statuses might be New, In Progress, or Closed. The use can Add, Edit, and Remove these from the lookup table at any time.
For this, I have a lookup table with Id, Caption, and Category. Other tables might have a StatusId that has an FK to Lookups.Id.
So, some questions:
1) Before they can remove a status I would like, to ensure that the Id isn't in use. I could query each table that it the target of the FK. Is there a simpler, more manageable way?
2) I would like to take action when the user selected the Closed option. How do I know for sure that this particular Lookup item was selected? Since it can be renamed I can't rely on the caption. I could have some other column in the table with some identifier in it and check that identifier in code, but that couples the code to a specific data item.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
Oh you are in for a world of hurt going down this particular rabbit hole.
Most/some lookup tables have a consequence in your code - how do you associate a new status with an action.
A generic lookup table simplifies the maintenance until you find a lookup that does not fit your structure (this always happens 2/3 through the project). I now have a table for each lookup type, I decide which ones can be edited. The delete procedure has to deal with FK and usage issues.
I recently got called a dinosaur by an out source architect for insisting on this structure, they then went down the generic path. I got a laugh when they ended up with a 3 table generic structure that was so complex the developers got lost trying to maintain it. F***ing whipper snappers.
Never underestimate the power of human stupidity
I noticed last week that the latest version of the Node Package Manager automatically audits your installation, checking installed versions against the data base of documented vulnerabilities in the NPM Registry. It delivers a very nice report, complete with instructions for automatically fixing many vulnerabilities by upgrading the affected packages. Other package managers (e. g., NuGet for Microsoft .NET, Composer for PHP, PIP for Python, PPM for Perl, would do well to implement such a feature, and probably will soon.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
The Data Mapper pattern is an effective way to decouple the domain model from whatever data storage system the application uses. However, one thing I noticed about it is that it does not explain how and when the data mapper should be notified that it needs to update the data.
I propose that the domain object notifies the data mapper (and, possibly any other objects that are interested) when one of its fields/properties changes via an event (I use C#, which supports events and properties and have the code to publish the event in the property's getter). The data mapper can then do whatever it sees fit to do with this information. Using events also inverts the dependency between the domain object and its data mapper.
Whenever a domain object is created in memory (either read from data or completely new), a data mapper should subscribe to its relevant events. There could be one data mapper per domain object or one per type of domain object. Additionally, the logic for creating, reading, and deleting domain objects need not be in the same data mapper that handles updates.
I don't think that update notifications are in the scope of the pattern. The Data mapper describes how persistence is handled, not when or why.
Other patterns, such as Repository and Unit of Work, can be leveraged in conjunction with a Data Mapper in order to provide the actual update logic. This is the SOP for current MVC.NET applications with EF.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli