Can you explain what are "retirable" entities in guidewire? How can we create these entities?
Also explain what is the difference between effdated entities and retirable entities?
Retirable entity is an extension of Editable entity. It has Retired field (boolean field) to do a logic delete.
EffDated entity also is an extension of Editable entity. It has EffectiveDate (Start date) and ExpirationDate (End date).
There are several differences but maybe the most interest for you is that effdated entity is used for entities that you are interest in know whole history (by example PolicyPeriod), then when you "deleted" an effdated item a new item is created with ExpirationDate modified to do a logic deleted.
Related
We have a requirement to delete certain products from everywhere in hybris (including cart, orders, promotions) and all its references as well like Media, Category, Stocks, etc.
I found this one solution:
REMOVE Product [batchmode=true];itemType(code)[unique=true]
;Product;
I was wondering if just deleting the product, would remove all its references from hybris, or is there any better solution to do this.
Any help is greatly appreciated!
Removing the product will remove references to it, but not the objects which are refering to it (like Media, Category, Stocks, etc.)
The only objects which will be deleted are those refered by attributes with the partOf modifier.
A Part Of relationship between two classes extends an aggregation
relationship by ensuring that the lifecycle of the dependant object
(the part) is bound to the lifecycle of the parent object. When you
delete the parent object, all instances of its attribute types that
are marked as partOf will then be cascade-deleted.
Hybris doesn't know if a Media or a Category is no longer needed after a Product is removed. Therefore you must delete those objects explicitly.
Removing product will remove only instances of product type, but not all data like media.
To remove from cart : it should inform user that product no longer available in store
For successfully placed orders : you should be able to display basic details of product with message as in cart [ :) :) But you should deliver if order is placed successfully and payment is received otherwise its a bad eCommerce impression]
For promotions : you should remove all promotions related to this product Or reconfigure according to business need.
I'am designing a new invoicing application. There are a number of features that I don't know how to implement in Core Data. I ask you for help with the following.
To keep things simple assume that there are 2 entities, Invoice entity and Detail entity with to-many relationship 'invoiceDetails' and to-one relationship 'detailInvoice'. Here are my questions.
Detail entity should have attribute 'sequenceNumber' which should be auto-generated when the user adds new detail. For each invoice the sequenceNumber should start at 1 and be incremented as the user adds new details. The sequenceNumber should be used to sort details within their invoice.
Detail entity has also attributes 'numberOfItems' and 'price'. It also should have attribute 'amount' which should be auto-generated as product of numberOfItems and price.
Invoice entity should have attribute 'netAmount' which should be generated as the sum of all detail amounts.
Invoice entity should have attribute 'vat' which should be auto-generated as an expression from netAmount.
Invoice entity should also have attribute 'totalAmount' auto-generated as a sum of netAmount and vat.
Invoice entity should have attribute 'dueTo' auto-generated from current date plus some number of days.
How do I accomplish this in Core Data application? Thanks.
/Mikael
Detail entity should have attribute 'sequenceNumber' which should be auto-generated when the user adds new detail.
You'll have to assign this value yourself. What I'd do is store the highest sequence number as metadata on the persistent store file (see NSPersistentStoreCoordinator's metadata-related methods). Any time you create a new instance, read the highest number from the store metadata, increment it, use that value on the new instance, and then save the new value back to store metadat.
2-6. Calculated attributes
These are generally handled by subclassing NSManagedObject and then overriding the setter methods on attributes whose value affects other attributes. For example, based on #2, the setter for your price attribute would look something like:
- (void)setPrice:(NSDecimalNumber *)price
{
[self willChangeValueForKey:#"price"];
[self setPrimitiveValue:price forKey:price];
[self didChangeValueForKey:#"price"];
// Now calculate the new value for "amount" and set it on self.
}
Follow the same pattern for each case. You can also use key-value observing to watch for changes on these attributes, but I find custom accessors to be clearer and less error-prone.
I am really new to MS Dynamics CRM .. and am stuck with understanding the Relationship and Mapping section.
I want to map the "city" field from Account entity to a "city" field in my custom entity "Custom".
For that I navigate to Account entity settings and create a 1:N relationship with related entity as "Custom" and then map the two fields.
Just like how all related data from "Lead" entity gets transferred to "Opportunities" after "Qualify", I want my custom "city" field to be filled with "city" from "Account" after i create a new account record.
This has something to do with workflows right?
Please correct me if I am wrong anywhere.
It sounds like you want to create a N:1 relationship on your Custom entity which points to the Account entity. If you are not looking for a lookup field, or if the entities are otherwise already related, then the “Mappings” feature of the relationship may be worth looking into. Keep in mind that this type of mapping only works when you are creating the “child” record from the “parent” record (with the parent form open). If you create the record “stand-alone” it won’t auto create the mapping. You can use workflows, however they run asynchronously and you may not see the result right away (which can confuse end users). Aside from that your options are JavaScript (not 100% reliable) or a custom code a Plugin.
So I've got a Client entity that needs a relationship to a PhoneNumber entity to allow multiple phone numbers. And I've got an Employee entity that also needs a relationship to a PhoneNumber entity to allow multiple phone numbers. Should I create two separate PhoneNumber entities or can I somehow use the same entity for both?
I would create a parent entity called Person for your Client and Employee entities. The Person entity would have a relationship to the PhoneNumber entity.
Inherited entities have the same attributes and relationships as their parent entity. Of course you can add attributes and relationships to the "child"-entities as well. I omitted that in the screenshot.
Something like this:
you can configure the parent entity in the core data inspector in the right side pane.
I am trying to do exactly same thing as post in NSFetchResultsController + sectionNameKeyPath + section order, i.e. basically use 2 tables, let's say Categories <-->> Events. Category table consists of category field only, while Event consists of name, dateTimestamp.
I defined relationship 'category' in Events table and try to use that relationship as sectionNameKeyPath when creating fetchedResultsController:
NSFetchedResultsController *aFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:self.managedObjectContext sectionNameKeyPath:#"category.category" cacheName:#"Root"];
Finally, I pre-populated Category table with some categories upon loading of the app (and verified with .dump that table is populated correctly)
Yet, I simulator fails on:
return [[self.fetchedResultsController sections] count];
I did extensive search and most people either suggest using one of the fields in the table as sectionNameKeyPath (this works!) or transient property (works too!) However, I just want to use relationship as it seems very logical to me in this case where events belong to some categories and there could be categories without events. Am I wrong in my assumption that relationship can be used as sectionNameKeyPath? The original link at the top of the question suggests it works, but guy does not know why or how. Documentation is very weak on what can be used as sectionNameKeyPath, so any help will be highly appreciated.
A relationship gets you a pointer to a managed object. It seems logical, though, that the sectionNameKeyPath parameter should be a key path that leads to a string, since NSFetchedResultsSectionInfo's name property is a string. The fetched results controller will follow that key path for each fetched object and group the objects into sections based on what they return for that key path, and it'll also use those strings as the names of their respective sections. You can't use a managed object for the name -- you have to use some string property of the managed object.
So, your Category entity must have an attribute that distinguishes one category from another, right? Use that as the key path and (as you've seen) everything will work out.
BTW, I think it's useful to try to get out of the database (rows/fields) mindset and try to think in object-oriented terms like entity and attribute. A big selling point of Core Data is that it provides an abstraction layer that hides the storage mechanism. Thinking in terms of tables is like thinking about blocks and sectors when you're reading or writing a file.
Caleb, thank you for your answer. I do believe my understanding was wrong to some degree. What I had was an entity Category and entity Event. Category has a string field 'category', thus 'category.category' path (first 'category' is relationship in the Event entity)
What I did not take in account, though, is that if there are no events, fetchresultscontroller cannot fetch anything (similar to 'left join')
What I wanted is to show categories even if there are no events. Relationship 'category' will not return anything in this case as there is nothing to return/sort/categorize.
What I had to do (wrong or right - not sure yet) is to treat [managed] object created from Category entity as a separate object in case there are no events and place in the table. When there is one event per category, I can switch to the original method of [automatic] showing events sorted by categories.
This is interesting issue of starting point (empty entities with relationships) where I feel core data is more confusing than traditional relationship database. I also believe that's why all books/articles/reports carefully stay away from this topic. In other words, I could not find analog of "left join" in core data. May be I am wrong because I am relatively new to all this. Below is the description of the entities:
Category <-->> Event
Category - parent
Category.category - attribute of type String
Category.event - relationship to Event entity
Event - child
Event.name - attribute of type String
Event.category - relationship to Category entity
Each event belongs to one category. Category may have multiple events.
Categories should be shown even if there are no events for this category.
I was trying to put Events under fetchresultscontroller. May be I should switch to Category first and then calculate cell based on category.event relationship, not the other way around - did not try that yet.