I have 2 tables - ClientAccount and BankAccount. Operations allowed are e.g. "buy" - that means transfer money from bank account to client account; and "transfer" - that means transfer money between two client accounts. I want to log both these events. To do so, I created a table Log, with sender and recipient fields, and now I need to define a proper way to define relationships between these 3 tables.
Firstly I decided to make recipient and sender as of ClientAccount type but in this case I cannot add info about "buy" operation (because sender in that case would be of BankAccount type).
Is there any way to create a superclass Account, which will be extended both by BankAccount and ClientAccount so I can use a simple Account type in Log table? What relationships do I have to define then?
You need Account parent entity and children ClientAccount and BankAccount. Then, you would be able to save account-account operation in the log.
It's up to you how to persist it in the database. Different ways are described here:
https://www.baeldung.com/hibernate-inheritance
Related
I am developing a system in which it will have a chat system between two user tables: the clients and the engineers. My problem is how to make these two tables communicate in one message table with regard to registering the sender ID and recipient ID since both can change and are in different tables.
My initial thought for this was two tables where I would use the polymorphic relationship:
chats
id
client_id
engineer_id
messages
id
chat_id
senderable_id
senderable_type
receiverable_id
receiverable_type
content
What would be the most recommended way to solve this problem?
First of all, the following its the generic way that I see to create a chat schem. It'll works to a chat with 2 users or more than 2 users.
Note, the user_chat table its the pivot table between users and chats. You can define an alias to that table, like "participants", because it what it means. You can add more attributes to chats table, but basically need to know the creator.
Finally, the secret in messages table is just to get the sender id from users table, because sender and receiver are relative concepts in this context.
Another more simple and reduced way to do it (if you are trying to make a chat with only 2 users) is:
In CRM Online I need to link the Account Name field in the Account entity to a lookup table of imported and approved company names. The goal is to require users to pick from an approved list instead of letting them make up a company account name. I know there is an Account Name lookup in Contacts which uses existing Account Name records, but I need the lookup in the Account entity. Thanks for any tips.
If you are referring to a different entity as LookupTable, then create a relationship between Account ans the Lookup Table entity. After that you can use that entity as Lookup attribute in Account entity
CRM renders a Lookup control for a 1:N relationship. What you are trying achieve would fall more into a data validation scenario where users can enter account names from a pre-set list of names.
You can leverage a new event introduced in CRM 2016 - addOnKeyPress which can be easily used to build an autocomplete feature which would be more inline with what you are trying to achieve. If a user doesn't "pick" a value instead types anything in disregarding the autocomplete use attribute control's setNotification to set an error message which would invalidate the save preventing the user from saving the record.
Suppose I have one aggregate, Ticket. A Ticket will have one assigned Department and one or more assigned Employee.
When instantiating a Ticket, should a TicketFactory be responsible for ensuring that a Ticket is created with a valid/existent Department and Employee?
Likewise, when decommissioning a Department or Employee, what is responsible for ensuring that a new Department or Employee is assigned to a Ticket so as to maintain its invariants? Could there be a service in the domain responsible for decommissioning, or is this a case where eventual consistency or some form of event listening should be adopted?
The TicketFactory would be declare that in order to create a Ticket you need references to both a Department and an Employee. It would not verify that those actually exist. It would be the responsibility of the calling code to obtain the appropriate references.
If using eventual consistency, the decommissioning of a Department and Employee would publish events indicating the decommission. There would be a handler associated with a Ticket which would subscribe to that event and either assign a new department and employee or send some sort of warning to task.
Take a look at Effective Aggregate Design for more on this.
I've recently started exploring DDD, so I have ran into some of the issues you mention.
I think that TicketFactory should always return validated/properly built Ticket instances. If you model is complex, you can have a domain service that validates that a given Department or Employee can be attached to it and then the factory uses it. Otherwise, you can just put it all in the factory. But what comes out of the factory should be a proper ticket.
I'd say that if e.g. only Ticket knows about the other two, a domain service that uses the Department and Employee repos would get the job done. If the relationship is bidirectional, then you can utilize event sourcing. Also, if it's really a event that should be captured in your domain model, and has other consequences other than reshuffling tickets, you can attach one of the handlers to this event to be InvalidTicketHandler. But if it's a small scale thing, keep it simple, just have a domain service that maintains the invariants.
Sidenote: If the Department and/or Employee are aggregates themselves, then you can reference them within Ticket via their identifier (e.g. employee's company ID or ID-code of the department). In that way you'll achieve consistency easier as you will not cross consistency boundaries between different aggregates.
A FACTORY is responsible for ensuring that all invariants are met for the object or AGGREGATE it creates; yet you should always think twice before removing the rules applying to an object outside that object. The FACTORY can delegate invariant checking to the product, and this is often best. [Domain-Driven Design: Tackling Complexity at the Heart of Software]
A depends on question type, but from the look of it it seems like a great candidate for an application layer functionality, i wouldn't go for the event solution though cause i find it only suitable in between layers and not between objects in the same layer.
I am writing a core data Cocoa application in which there are accounts and transactions (monetary). The account entity description contains a balance attribute. The transaction entity description has a relationship to an account.
I need the application to update account balances when transactions have their accounts set or changed. For example, if a transaction's account is changed from checking to credit, the balances of both checking and credit should be changed to reflect this.
The problem I am having is that I am unsure how to determine the transaction's old account so I can update its balance. I am using bindings.
Can anyone point me in the right direction?
I assume that the account entity has the inverse relationship to the transactions. (Apple strongly suggests you always have inverse relationships. So if you haven't, please set it up!)
Let's say you have a subclass Account of NSManagedObject for the account entity, and Transaction for the transaction entity.
Call the inverse relationship to transactions as transactions.
Then, when you change the account for the transactions, the inverse relationship is automatically updated by CoreData. So, all you have to do is to write a self-observation routine for transactions in Account so that the Account objects keep track of the balance themselves. I think it is more object-oriented-y to make Account objects to take care of themselves than changing the balance from the side of the Transaction object... although of course it depends on your taste.
To perform the observation, you use KVO. Basically, you register the KVO by addObserver:forKeyPath:options:context: with a suitable set of options. Then, you get the change by implementing observeValueForKeyPath:ofObject:change:context:. The changes can be found in the dictionary passed to that method.
I'm trying to write my first Cocoa app, and Core Data is making it difficult to model my data objects. I have two entities that I want to manipulate: Account and Transaction. Account has a human-readable name and that's about it. Transaction stores a monetary value, and references to two accounts called debitAccount and creditAccount (I'm working on a double-book accounting app).
I want to be able to find all the Transactions for a given Account, whether they use debitAccount or creditAccount. How can I do this? Is there a way to do it that will work easily with Cocoa UI binding?
If I understand you correctly, you want Transaction to be related to Account via two relationships: debitAccount and creditAccount, yes? And you're wondering about creating inverse relationships.
In short, a relationship can only be the inverse of one other relationship. So you won't be able to create a relationship called, say, transactions that is the inverse of both debitAccount and creditAccount. Instead, you'll have to create two relationships, like debitTransactions and creditTransactions (I'm sure you'll think of more appropriate names for these...)
Now, since relationships are modeled as sets (specifically, NSSets), you can union the creditTransactions and debitTransactions relationships for a particular Account to get all transactions that account is involved with.
A (possibly better) alternative would be to introduce an intermediate entity, with a name like TransactionAccount that has a to-one relationship to both Account and Transaction as well as an attribute, like accountRole that identifies the account as being the debit or credit account relative to that particular transaction. You'd create inverse to-many relationships on both Transaction and Account with a name like transactionAccounts. That way, you could write something like this:
[account valueForKeyPath:#"transactionAccounts.transaction"]
to get all the transactions for a particular account. You could use an NSPredicate to filter the set to only transactions where the account was the debit/credit account.
The solution that worked best (and made the most sense) to me was to create a subclass of NSManagedObject to use as my Account entity:
#interface Account : NSManagedObject {
}
-(NSArray*)getTransactions;
#end
I have the actual lookup logic inside -getTransactions, which wasn't too hard to do by hand. This is working out well so far, especially because the method name conforms to KVO.
To make Core Data return Accounts instead of NSManagedObjects, I had to change the entity's "Class" property in Xcode's data modeling tool.