We have below three state of object in BI 4.x business layer.
Active (will use for reporting).
Hidden (will not available for reporting).
Deprecated (will not available for reporting).
Both hidden and deprecated objects will not available for reporting and both type of object we can convert into active object in future.
Can you please let me know difference between hidden and deprecated objects and in which scenario we will use the deprecated object in our universe.
Thanks,
Sachin
Active: Object is visible in the Query Panel. This is the default state.
Hidden: Object is valid but not available in the Query Panel (used by other objects as a hidden object).
Deprecated: Object is hidden and not valid. One possible use for this state is when the target database field no longer exists, but you want to keep the object for possible future use.
https://help.sap.com/businessobject/product_guides/boexir4/en/xi4sp6_info_design_tool_en.pdf
Related
In Unity you have to tell the engine which are the parameters to serialize.
Not only that, some of them are not serializable (like dictionaries, for instance), and you need to specify it very clearly and carefully.
I'm really confused to find nearly no documentation in any book or official page about it. Not even questions in the forums. Seems like a blueprint thing only... and not really it.
What I need to know if the state of the editor variables state are stored in the scene when you save it (serialized) and also when you enter Play Mode.
How about creating instances of a component whose UPROPERTIES values are also set in the editor but created using Macros from other files. Those are quite dynamic. Are those stored too?
(I understand that the constructor is executed everytime you open the scene. I'm only interested in this case... not creating the instance via code, since you can set those values hardcoded)
I'm running tests, but would help some information about all this. Maybe Unreal stores every single thing and that's why there's no info about it...
As far as I know about UE serialization, variables marked with UPROPERTY macro are subjects to a CDO mechanism (or at least those marked as EditDefaultsOnly, EditAnywhere and similar Attributes that lets you edit it's value in editor). CDO is Class Default Object and basically it holds initial data for UObjects.
Values of those properties could be set in C++ or editor and later changed (overridden) on actual instances or defaults of derived classes (meaning Blueprint classes as well). If you don't want to store value of a property, you can use Transient flag (c++) or checkbox (BP). I often use it for cached items which I find during gameplay.
Note, that in C++ constructor, those properties are not correctly initialized. And they are not correctly initialized until PostInitProperties() is called, which is after CDO initialization.
I found usefull reading about Actor's lifecycle UE Docs and it helped me a lot.
I have questions about the NSUndoManager methods
registerUndoWithTarget:selector:object:
prepareWithInvocationTarget:
Usually in examples, the "target" is a controller object that manages all the model objects (usually in an array).
But can the target be an individual model object - the model object to be changed by the undo/redo operation?
The guide says about registerUndoWithTarget:selector:object::
The target object may not be the actual object whose state is changing; instead, it may be the client object, a document or container that holds many undoable objects.
Why this restriction? It is not mentioned in the documentation for the method itself. Also, no such restriction is mentioned for the prepareWithInvocationTarget: method.
The docs you quote are a bit ambiguous. I would read this:
The target object may not be the actual object whose state is
changing; instead, it may be the client object, a document or
container that holds many undoable objects.
as this:
The target object might not be the actual object whose state is
changing; instead, it may be the client object, a document or
container that holds many undoable objects
However, it's usually best not to use a model as the target. The target is not retained, so it could be deallocated while still referenced on the undo stack. Targeting a controller that owns the undo manager is a good idea.
When i am trying to add any object from website to local object repository,it is not possible because for each object it is showing same properties.so for descriptive programming it is difficult to mention the property value.
If each object is showing same properties then the either app is not properly recognized by qtp or you have not selected a proper add-in.
For Example, flex applications are not recognized by qtp without customization and qtp will all the objects as MacromediaFlashPlayer object.
Kus, QTP 11 has a feature called Visual Relation Identifiers. By the name itself, it helps you identify objects, based on their visual proximity to the other objects in your screen, rather than by their actual properties. This is the remedy for cases when the objects in the AUT are very similar to each other.
This feature is available under the Define New Test Object window.
Update:
Since you're bound to QTP 10, I suggest using location or ordinal identifiers. Here, the idea is that even if you have 3 objects that are exactly the same they will at least appear on different locations on the screen and QTP can use that order to identify which object you want to act on. It reads from left to right.
Let's say you have 3 textboxes named "inputField", you can identify them this way:
.WebEdit("name:=inputField","location:=0").Set "1stTextBox"
.WebEdit("name:=inputField","location:=1").Set "2ndTextBox"
.WebEdit("name:=inputField","location:=2").Set "3rdTextBox"
Read more at this link: Ordinal Identifiers Demo.
I am trying to implement a straightforward associative array (no duplicates) with string keys and instances of my own "classes" as values in JavaScript. I am happy with expected O(1) behaviour of a hash set or the O(log n) access time of a set implemented as a balanced tree.
I am drawn to the simple use of an object to which I dynamically add new properties but I am on Node.js and have come across the V8 optimisation of hidden classes (see description of V8 hidden classes here).
If I do use properties on an object, will the V8 runtime notice the sheer number of properties and their transience and stop trying to JIT hidden classes behind the scenes?
I just cloned the V8 code, so pointers into it would be welcome alongside the top-line answer to my question.
Thanks for your help.
Follow-up 1
Thanks #vyacheslav-egorov, I see the guard code below in JSObject::AddFastProperty at your link. Without digging through more code it seems like a lot of overhead on every new property insertion. I think I see something like a per-object mode which causes JSObject::AddFastProperty to never be called any more. So JSObject::AddProperty calls straight through to JSObject::AddSlowProperty without much fuss. Do I need to do anything to push an object into that mode, or will the V8 runtime switch it over reliably using its own metrics?
if ((!name->IsSymbol() && !IsIdentifier(isolate->unicode_cache(), name)
&& name != isolate->heap()->hidden_string()) ||
(map()->unused_property_fields() == 0 &&
TooManyFastProperties(properties()->length(), store_mode))) {
Yes, V8 switches object properties to a dictionary representation when it notices that object has too many properties.
How many is "too many" depends on several factors (how was the object created, how many properties it had initially, how are properties added to the object). For example if an object was created as an empty object literal "too many" would be around 30 properties.
I'm considering using flexjson to serialise my business objects to a file in an android application, simply using JSONSerializer().deepSerialise(myObject) and JSONDeserializer().deserialise(jsonString) with all the default transformers and object factories.
I'm hoping that once the application is released any changes to the business model should be accommodated by writing flexjsons transformers and object factories in the new release to maintain compatibility with previous versions.
What I'm not sure about is what changes the default transformers and object factories can cope with.
i.e if I add a field to a class and deserialise from an old version without the field into the new class will it fail or will the new field be null or 0 (if a number). Same question if I remove a field, what happens.
In standard java serialisation this is all documented here..
http://docs.oracle.com/javase/7/docs/platform/serialization/spec/version.html
But I cant find the equivalent information for flexjson, that deals explicitly with the issues surrounding versioning of objects, Is there any?
Cheers,
Phil.
Flexjson will look at the JSON first to find any fields it contains, and then looks for those fields on the Object you are deserializing into. So adding new fields to an object will not cause the deserialization process to fail. The new field will just not be populated from the JSON object (ie it will retain the value(s) set in the constructor or the initialization values).
If you remove a field from an object in the future Flexjson will simply not deserialize that value into the object because it won't find a setter for it.
So you can think about the getter/setter functions as a declaration on the JSON of what you want out of it. You aren't required to serialize/deserialize all values from the JSON object.
The only part that gets really tricky is if you rename fields, or change types on a field. Renaming field can be handled by keeping the older setter around and internally setting the new field in that older setter. You can mark it private or protected to hide it from the outside and Flexjson will still use it. If you change the type it is much more tricky. One option is to keep the older setter with the prior type around (like setFoo(String) and setFoo(List)) and adapt to the new type. The other option is to write your ObjectFactory to translate between to the two potential types. This of course is the hardest to do. The last option is don't do this without changing the name of the field, and use one of the other methods to translate.