I've got a BizTalk solution where I added a schema, and promoted a field
- this added the default PropertySchema.xsd with the element in
A bit later, added another schema, but when I try and promote a couple of fields, but when I select Show Promotions, I end up mapping the new field to one of the existing fields in the PropertySchema
My bad ... I should have used the Quick Promote
You can manually add items to the property schema as you would with correlation and then associate the promoted property.
Related
I am trying to get a snapshot of deleted userstory to get value for a custom field(c_Dep). I get the snapshot but the custom field is empty. It had value in it. Does lookback not save value for cutomer created cutom field?
findConfig: {
_TypeHierarchy: 'HierarchicalRequirement',
"ObjectID": 12345,
"_ValidFrom": {
"$lte": "2017-01-25T19:00:57.475Z"
}
Sarita, It is hard to tell from the information you have given what is going on precisely. However, I can give you some pointers
The Lookback API will store changes in values for custom fields. The selection you have shown is valid from 24thJan to 25thJan. During this period was the custom field set? Probably not, because the array is only one long and I think it is showing the creation event.
Was the custom field updated to contain something after this time period?
The reason for asking is that a common misunderstanding is that the records stored in the lookback database will hold the current value of fields - it doesn't. It holds the changes in fields. If c_Dependencies didn't change during that time period, you may not see an entry returned in the array. The next entry in the database might be the record where the c_Dependencies field was set (changed from null to something) and that might be 'after' your time period filter.
It looks like your query is requesting snapshots earlier than 2017/1/25 ($lte). Since there's only one, it's probably the creation snapshot. If you get all snapshots for the ObjectID by removing the _ValidFrom parameter, you should see the changes made to c_Dep after artifact creation.
As I am not allowed to comment, I have to post a new answer.
I think William Scott meant remove the ValidTo filter. The one you have is the creation change. The update will be afterwards.
I am working in odoo9. Now I needed a view that permits the user to select partner and get his sale history.
Now I created a model "sale.history" but it saves the selected data as a record in db. I really don't need this.
How can I create a view for this.
Please also see this image.
You have two options for such views/reports.
Use TransientModel instead of Model for the model inheritance. Transient model records in database will be deleted by a frequently running cron job. The email message PopUp/Wizard is a nice example for that.
Write your own report (database view) for sales order. Actually there already is one report for that: Reporting/Sales/Sales Analysis. The model for that report is sale.report if you want to know, how it's done.
Aside from using a TransientModel (old api) or AbstractModel (new api)...you can simply set the store property of field to false, that way your field will never be persisted to the database, it will simply be a 'view field'.
class sale_history(model.Model):
_name='sale.history'
partner = fields.Many2one('res.partner', store=False)
The partner field will never get saved to the database
You can use store=False on the field in the model (as danidee suggested).
You can also overwrite the create method on the model.
Question - what is the purpose of the "sale.history" model? If it does not store any data at all then you may be better off creating a new view against "res.partner" rather than creating a new model.
So, many times before when I needed to add a property to an entity, I created a new version of xdatamodel file and performed lightweight migration, that automatically added this property to all already existing NSManagedObjects.
But now i need no only to add property, but also to fill it with a value, that can be calculated using another existing property.(Ex: I have an entity User with property "name", and now I need to add a property "hashname" = [user.name base64],so that all my existing users have this filled property)
So, is there a way to do it using migration? (I know that it's possible simply select all users without hashname and fill it manyally after lightweigt migration, but i want to know if migration technology provided by apple can do it for me)
You have to do it "manually". The only automatic filling of a property is with a default value, but that would not be dynamic.
You don't need to actually add calculated properties to the model. Just create an NSManagedObject subclass that includes this property and calculates it from its other attribues.
According to the REST philosophy, a PUT request should update the resource at a URL if it exists, and create it if it doesn't exist. So in other words, if I use the following URL:
PUT http://server/item/5
If an Item exists with an ID of 5, it will be updated. If an Item doesn't exist with an ID of 5, a new Item will be created with an ID of 5.
However, I'm using NHibernate for persistence, and I mapped my IDs as Identity. This means that no matter what value I assign the ID, NHibernate will replace it with its own when I save a new Item.
How do I get NHibernate to save an Item with the ID that I assign it, without changing the ID mapping to Assigned?
If you use Identity, the DB won't allow you to enter a value.
That said, if your DB has some special syntax to allow inserting with explicit values in Identity fields, you can implement your own generator, which I guarantee will be error prone, hard to debug, and not very useful. But it's possible.
Study everything in https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/trunk/nhibernate/src/NHibernate/Id and start creating your Frankenstein :-)
I'm going through an XML file of articles and the journalist(s) that wrote them. As we are adding the articles into _Data our datacontext we may come across a journalist that needs adding so we do this:
newJourno = New journalist With {.name = strJournalist}
_Data.journalists.InsertOnSubmit(newJourno)
.articles_journalists.Add(New articles_journalist With {.id_journalist = newJourno.id, .id_article = .id})
However subsequently we may come across this same journalist again and nothing is returned when we do this:
Dim journo = _Data.journalists.Where(Function(s) s.name = strJournalist).SingleOrDefault
So it uses the code above again to insert the same journalist again.
Once all of our inserts are done we do a submitchanges. At this point it has a head fit:
INSERT statement conflicted with COLUMN FOREIGN KEY constraint 'FK_articles_journalists_journalists'. The conflict occurred in database 'blah', table 'journalists', column 'id'. The statement has been terminated.
From looking through the sql generated in sql profiler you can see that it is trying to add some journalists more than once, this will fail as the name must be distinct. The subsequent records that are trying to be inserted with these journalists are failing as the journalist wasn't updated.
Surely if I have a collection of journalists, add some to it and then look in my collection I should see all of them and not just the original ones. I can fudge it I guess by doing a submitchanges but that seems a bit silly.
Thanks in advance,
Dave.
If you want to add two child-parent rows to the database, you must assign the entity, instead of the Id column, the Id will be autogenerated and will be available only after the submit changes.
You have to do a articles_journalist object, and then assign the newJourno entity to this:
articles_journalist.journalist = newJourno;
CMS is right about needing to assign the object, not the id.
However this doesn't seem to get around the problem of the datacontext not realising that it has had new stuff added to it until you submitchanges. I can only presume this is by design and therefore I am now calling submitchanges as and when the code inserts objects that we later search for.
"the name must be distinct."
This is a serious design flaw. Person names are never unique.