I was given the following question:
An entity that is related to another entity through a generalization hierarchy, then... It will always have a total participation with respect to the "father". T/F and justify
Well, I think it is true because it must be related to the another entity (that's the meaning of total participation).
I do not understand such a question. Can you clear my mind?
In a generalization hierarchy, child entity sets are subsets of their parent entity sets. That means all child entities ARE parent entities, rather than that child entities are related to distinct parent entities as in a containment hierarchy. Subtyping/supertyping isn't a true relationship type in the entity-relationship model.
That said, it's true that every child entity must be identical to a parent entity, and since identity can be viewed as a trivial relationship, it's not wrong to say that child entity sets participate fully in that relationship.
Related
The Axon documentation describes how to create a child aggregate from a parent, but not how to retrieve it, or delete it (e.g. for cascading deletes)
Does the parent aggregate typically-explicitly, or automatically-internally keep a list of references to the child aggregates?
Would such references be a collection of aggregate IDs, or, to be more object oriented, a collection of actual instance references to the child aggregates?
Another way to pose this question: What is different about child aggregates vs entities in multi-entity aggregates, and what is different about child aggregates vs totally independent aggregates?
I want a cascading delete (containment) model between parent and child, but I want separate concurrent access to the child objects in a very large collection, hence aggregate member entities are not suitable.
Also note a similar question in the forum: the OP, Jakob describes a model at the end that includes his own table managing references for cascading... do I need that?
If you require the Entities to be separate Aggregates, then you will be required to maintain a reference table from parent to child.
The support Axon provides to create child Aggregates from a parent Aggregate is to ensure the framework uses a single transaction to publish multiple events. By no means does Axon Framework automatically store the relationships for you.
Instead, all of this should be known within the event stream of the Aggregates. With that in mind, combined with Event Sourcing, you can source any form of data within the Aggregates.
To circle back to your cascading delete scenario: I've actually had direct contact with Jakob about the matter. In his case (and potentially yours) we ended up with an `aggregateId-to-childAggregateIds model dedicated to keeping the references. Upon a delete from a parent Aggregate (on any level), this model is referred to, ensuring the right set of children is deleted too. Note that all this is custom code.
Furthermore, this aggregateId-to-childAggregateIds model can be regarded as part of your Command Model (granted that you're aiming to apply CQRS). As such, it's purely used to drive decision-making. Where the decision-making, in this case, is deciding on the right children to send delete commands to.
So, to summarize:
Axon does not keep parent-child relations for you, other than in the contents of the events you publish.
I'd opt the aggregateId-to-childAggregateIds model to never store the entire Aggregate instance. You simply don't need all that data for deciding who to delete. The child's Aggregate identifier should suffice.
Axon's child Aggregate creation support is purely there to use a single transaction towards the event store to publish the parent's change and the creation of a child, while still benefitting from separate instances for increased concurrency. Axon's Aggregate Member support would mark the children as entities under the parent Aggregate Root instead of their own Aggregate instances.
I have an entity that represents a relationship between two entity groups but the entity belongs to one of the groups. However, my queries for this data are going to be mostly with the other entity group. To support the queries I see I have two choices a) Create a global index that has the other entity group key as prefix b) Move the entity into the other entity group and create ancestor index.
I saw a presentation which mentioned that ancestor indexes map internally to a separate table per entity group while there is a single table for the global index. That makes me feel that ancestors are better than using global indexes which includes the ancestor keys as prefix for this specific use case where I will always be querying in the context of some ancestor key.
Looking for guidance on this in terms of performance, storage characteristics, transaction latency and any other architectural considerations to make the final call.
From what I was able to found I would say it depends on the of the type of work you'll be doing. looked at this docs and it suggest you Avoid writing to an entity group more than once per second. Also indexing a property could result in increased latency. Also it states that If you need strong consistency for your queries, use an ancestor query, in that docs there are many advice's on how to avoid latency and other issues. it should help you on taking a call.
I ended up using a 3rd option which is to have another entity denormalized into the other entity group and have ancestor queries on it. This allows me to efficiently query data for either of the entity groups. Since I was using transactions already, denormalizing wouldn't cause any inconsistencies and everything seems to work well.
A strategic question… When a state is going to have one to many type of data, should we always create a collection under the parent state object or create a separate state object for the child with the reference to parent? Example (Employer 1:M Employee) or (Employer 1:M Location) …. When to decide which strategy? I've listed some PROS & CONS for each. Not sure when to use what strategy. Looking for some feedback
Adding child as collection
PROS
=====
- Easier to manage from coding standpoint
- Easy access to child data as it will always be available when querying parent from vault
CONS
=====
- As each collection object is going to be represented as separate table in the database, Each time a new state is created child data is also replicated even though there may not be update on child which will cause database to grow unessential
- If we have too many of such collection objects then serialized transaction size could be huge so performance could be worst
Adding child as Separate State Object
PROS
=====
- Child data is not replicated with each time a new parent state is updated
- When there is an update on any of the Child data only that state needs to be communicated other participant
CONS
=====
- More coding needed in order to manage child state object separately
- Child data won't be available when querying parent from vault
- Each state needs to have its own contract so child objects can't be validated on the same parent contract
Since states are linked to persisting to a single table on the backend, it is difficult to manage child collections. At present, I think you would need to leave the collection property unbound (i.e. not mapped to a database column and marked as transient so that the class can still be serializable) and then do a separate filtered query for the child records that can be assigned to the collection property of the state. Then when any change is persisted, it will not try to persist the child records. Changes to child records should be done individually through their own state transactions. It would be nice if Corda had a feature that would support the JPA feature of doing joins between tables such as #OneToMany. This would facilitate queries, but persisting state changes would still need to be handled separately. There may be a way of doing this that I am unaware of.
It's an old question, but there does not seem to be an accepted answer, so I'll have a go.
Firstly, the Corda node is not just a back-end for your application, it's a node in a decentralised transaction processing system. The latter must be key requirement for you, otherwise you wouldn't use Corda.
Secondly, Corda implements UTXO (Unspent Transaction Output) paradigm for evolving distributed state through a series of transaction whereby a collection of objects representing input states are 'spent' (or consumed, become unavailable) and replaced by another collection of objects representing output states. The state objects themselves may have complex structures, but when they evolve they meant to be swapped as a whole. That is unlike, say, Ethereum or Hyperledger, where the global state is basically a large collection of unrelated key-value pairs that can change arbitrarily. UTXO model allows to easily implement features that are very hard to achieve with the global state model, such as transaction privacy. Important point here is that Corda can be made to emulate global state model, but it will be inefficient at it and lose most of its benefits.
Because of this, the way states are modelled must be based on the intended evolution of the distributed state of a CorDapp. The questions to ask yourself therefore are probably the following:
Will the child states 'live their own life', i.e. evolve
independently from the parent states? An example of a 'yes' would be
Corda Token SDK, whereby token type and tokens themselves are
separate states despite obvious parent-child relationship. Network
participants can trade the child states without controlling the
parent state.
Will there be a need to withhold the information in
a parent state but not the child, or vice versa from a party
participating in a transaction? An example of a 'yes' would be the
use of Oracle to sign off a child state object output without being
shown the parent. Corda IRS example does something similar with
transaction tear-offs when the Oracle fixes the interest rate.
Will there be a situation whereby a network participant may need to
know (i.e. keep in the vault) the child state, but not the parent
state. An example of a 'yes' would be an off-ledger settlement
workflow similar to the Corda Settler example, whereby paying agents
can be settling obligations without necessarily knowing the details
of the agreements that led to the obligations to arise.
If the answer to any of the above questions is 'yes', then you have to represent the children as separate states, otherwise it is better to leave them embedded into the parent state.
How does Corda support parent-child relationship between states ( i.e. one parent state to many child states that serve different purposes ) One-To-Many Relationship. Currently I am only doing it by adding the reference number ( linear id ) of the parent state into each child states.
Elaboration:
The parent states consist of common information shared by each child states, While the child states would consist of information that is only relevant to itself. Each child would evolve or transition to different lifecycles independently, unless if an action is taken upon the parent state, i.e cancellation, early expiration, it would cascade to all the children states linked to the parent. Likewise, if all children states have evolved to their end of lifecycle i.e SETTLED, the parent must be able to collate and transition itself to SETTLED as well.
An example scenario would be a buyer who would issue a purchase contract with a seller, which also consists of different items. So in one purchase contract, there may be different products, and each to be shipped to different locations. But once all items have been shipped and accounted for (SETTLED), the purchase contract is only then SETTLED.
Just reference the child states in the parent state by their linearId, or vice-versa.
You can then impose rules in the contract - for example, you can require that a transaction marking a purchase contract as Settled is also transferring all the items from the seller to the buyer.
Let me know if the use-case evolves and this model is no longer appropriate.
I feel pretty lost on collections, and entities as it stands.
My purpose:
A user will have one or more abilities. There are a set number of abilities, and numerous users. (A user entity, usertoabilities, abilities)
I want to display a form of the set abilities (lets say running, swimming, climbing), with properties such as (skill level, length of time).
The user would check each ability they have, and select their skill level and time.
My current understanding, is that my form will contain:
a collection of abilities (collection of entities), a collection of skill levels, and a collection times.
The form will print out each row of abilities with the corresponding properties. Where the user selects these abilities and saves them.
Is my understanding correct?
My current approach seems to have me going in circles.
you can create only two Entities (User and ability) and you need to create a ManyToMany Relation where you need to set a field (property) that is the relations field with some annotations where you wil set the "JoinTable" that in this case is "usertoabilities" for the two entities and more fields that will be the "abilities" you can find more information in http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html