In my Block A state machine, I'm trying to use the value of Block B's value property, but for some reason it won't let me. Is there a way to use another block's value property in a state machine?
It should be easy if block A has a reference to Block B and the values are not private. Then in the state machine code it would be somthing like itsB.getSomeValue(); The exact syntax will change depending on which language you are using.
Here is a test sample I made:
So if the client wanted to access something on the clock it would just use its itsClock reference. Here is an example of the client accessing it from its state machine:
Related
I have a set of events that have been refactored to another package. This works as is until I execute the event replay. Digging deeper I noticed a payloadtype in the domainevententry table and figure changing this would be sufficient but alas it seems the xml root element of the event needs to be changed as well. I am hoping there is a simple way to do this.
I cannot find any examples on upcasting to different packages or using XStream aliasing so any help would be greatly appreciated.
Thanks
As you noticed, the default payload type stored in events is the fully qualified class name. This ensures that out of the box serialization and deserialization work as intended. However, moving classes around thus means the payload type can no longer be found, requiring some adjustment to be made.
You could have used the EventTypeUpcaster, as referred to in the Reference Guide. The EventTypeUpcaster is dedicated to adjusting the payload type, and thus can also be used to deal with changing package names.
When using (the default) XStreamSerializer, aliasing the tags would indeed also work. How to set aliases can be seen here for example. AS noticed in that sample, the alias is added to the XStream instance. The XStreamSerializer uses an XStream instance to support de-/serialization from/to XML. To adjust the XStream instance, you can simply use the builder paradigm on the XStreamSerializer. The JavaDoc of the builder should be specific enough to help you out how to use it.
Went the long way round with this but it seems to work. As always, backup your database before executing large volume changes. I also restarted the service using the database on completion. Needless to say I will make sure the events are in logical packages before deploying next time :)
Database Engine: Postgres 10
Table: domainevententry
update domainevententry
set
payloadtype = '<new.package.Classname>',
payload = lo_from_bytea(0, decode(REPLACE(
subquery.output,
'<old.package.Classname>',
'<new.package.Classname>'
), 'escape'))
from (
SELECT eventidentifier, payloadtype, encode(lo_get(payload::oid), 'escape') as output FROM domainevententry
WHERE eventidentifier in (
'<event guid 1>',
'<event guid 2>'
)
AND payloadtype = '<old.package.Classname>'
) as subquery
where domainevententry.eventidentifier = subquery.eventidentifier;
Once that is completed I needed to update the OWNER of the large object:
ALTER LARGE OBJECT <LargeObjectId> OWNER TO database_role;
Probably not the most elegant solution but based on the time constraints I have, it did the job. There are probably encoding issues with this solution for the large object but it all worked out for me in the end. Feel free to share any optimizations that would make the above more suitable.
Firing off the Axon Framework replays rebuilt the projections and everything lined up.
I am trying to use Serilog in my .Net Core API to log to SQL Server with the Serilog-Sinks-MSSqlServer sink. The standard Level column either writes out the full value (e.g. Information, Warning, Error) or a TinyInt enum value if you set the StoreAsEnum property to true as shown here. I cannot seem to find an easy way (like there is in Log4net and NLog) to format the output to write only the first character of the Level (e.g. I, W, E). I tried setting the DataLength property to 1 but that causes the log entry to not be written at all.
I have been able to accomplish my desired behavior with a custom enricher that takes the Level value from the standard column and then uses just the first character to write to a custom column while removing the standard Level column but that really seems like overkill when I feel like there may be a formatting mechanism somewhere that I just haven’t seen.
For Serilog.Sinks.MSSqlServer, it does not expose easy way to custom the Level value.
If you check MSSqlServerSink, you will see that it convert IEnumerable<LogEvent> events to _traits.eventTable by a private method, which means you could not override the method void FillDataTable(IEnumerable<LogEvent> events).
In addition, for MSSqlServerSinkTraits, it is internal, you could not inherit from it to implement your own MSSqlServerSinkTrait.
There is no much thing you could not if you want to override something from Serilog.Sinks.MSSqlServer.
For easiest way, you may consider forking the Serilog.Sinks.MSSqlServer, and change GetStandardColumnNameAndValue from below code
case StandardColumn.Level:
return new KeyValuePair<string, object>(columnOptions.Level.ColumnName, columnOptions.Level.StoreAsEnum ? (object)logEvent.Level : logEvent.Level.ToString());
to change logEvent.Level.ToString() to your expected value like logEvent.Level.ToString().Substring(0,1).
Then build the project and reference this project instead of Serilog.Sinks.MSSqlServer
I am familiar with bindings with curly braces, like {{variable}}, from Polymer 0.5.
However, in examples and code snippets for the release version of Polymer, I've begun to notice bindings with square brackets, such as [[variable]], as well.
Does {{variable}} mean something different now, or is it the same and [[variable]] is just an addition? What is the difference between binding to [[variable]] and {{variable}} in Polymer?
Just as you've noticed, there are now two different syntaxes for data-binding, which have different purposes:
{{variable}} indicates that you would like Polymer to automatically detect whether or not the binding should be one-way or two-way.
[[variable]] indicates that you want the binding to one-way only.
Why the change?
Polymer 1.x differs from older versions is that bindings are now one-way by default, much unlike 0.5, where they were always two-way.
In other words, if you write
<my-element some-property="{{myVariable}}"></my-element>
then by default, when
myVariable is changed, Polymer updates the binding, and thus updates my-element's someProperty.
someProperty is changed, Polymer does not update the binding to myVariable.
This is always the case unless you set notify:true on the property inside my-element:
Polymer({
is: 'my-element',
properties: {
someProperty: {
notify: true,
...
With notify: true, the binding is now two-way, so when
myVariable is changed, Polymer updates the binding to someProperty.
someProperty is changed, Polymer also updates the binding to myVariable.
This behaviour (when using notify: true) used to be default in 0.5; now you must ask for it explicitly.
When to use [[variable]]
There's no technical reason why you must use [[variable]], because Polymer will automatically detect whether bindings are one or two-way with {{variable}}. So why would you use it?
Let's say you're working in a large project, and you know that based on the way that data flows in a particular page/element, a certain property should never be changed by the element it is being bound to, for example in the case of an element which functionally serves a purpose as a label:
<display-data source-data="{{data}}"></display-data>
...
<data-editor source-data="{{data}}"></data-editor>
Everything looks good! The data property is bound to both the display-data element and data-editor elements, and will be automatically shared between them. (In this example, assume display-data's sole purpose is to preview the data that it is bound to.)
One day, you or someone else is editing display-data, and you forget about the situation in which it is being used in above. For an entirely different use-case, you or the other developer would like display-data to also format or otherwise modify the data it is given and push it back towards any other elements that may be bound to it. You/they edit display-data as such:
Add notify: true to sourceData, to allow two-way data-binding.
Add code into display-data which modifies the sourceData property.
This works great for all the pages that needed this functionality. But on the page mentioned before, this was not intended and ends up garbling the data that data-editor sees!
This problem would have been avoided had:
The dev team communicated better and had been more considerate of where elements are being used,
and/or [[data]] was used instead of {{data}} in the page/element in question.
With
<display-data source-data="[[data]]"></display-data>
...
<data-editor source-data="{{data}}"></data-editor>
data-editor can change data, but display-data will only ever be able to read data, and won't be able to change its value when it changes the value of its sourceData property, even when notify: true is set on sourceData.
Therefore, it could potentially be a good idea to:
Use [[variable]] whenever you need to bind to variable. This way, you enforce the direction through which data should flow in your element/page/application.
Use {{variable}} whenever you know that the binding must be two-way.
According to the documentation,
To make your code more easier to read, you may want to use the [[property]] form by default, and only use {{property}} for two-way bindings.
This being said, however, it ultimately comes down to a matter of choice. If you want to forego the use of [[variable]], no one is stopping you and you will not start any fires.
I found this in rtt-estimator.h the constructor sets the value for m_initialEstimatedRtt which I believe directly controls the Retransmit Timeout value.
I am not sure how to set the value for m_initialEstimatedRtt.
I see a method named SetCurrentEstimate that could be used to change that value but I am not sure at what stage in the simulation I should modify it if I use that so I prefer to control the initial.
Also I'm wondering what is the default value set in the examples and where can I find it?
There are many ways to set that variable, chiefly through the attribute system. The attriobute associated to that variable is ns3::RttEstimator::InitialEstimation from rtt-estimator.cc)
If you have followed the standard script layout, all you need is to use the following command-line argument:
--ns3::RttEstimator::InitialEstimation=1.0s
The tutorial gives a gentle introduction to the use of attributes through the command-line and environment variables:
http://www.nsnam.org/docs/release/3.19/tutorial/html/tweaking.html#using-command-line-arguments
There are more details there:
http://www.nsnam.org/docs/release/3.19/manual/html/attributes.html
You might find the ConfigStore useful too:
http://www.nsnam.org/docs/release/3.19/manual/html/attributes.html#configstore
I'm having trouble setting the property of a control on another state.
Latest_News_Display is under the Latest_News state. I want to set Latest_News_Display's x property even if the currentState is set to Intro. However, when I try to use Latest_News.Latest_News_Display.x = 10,it returns an error that says 1120: Access of undefined property Latest_News. So how do I go about doing it?
There is no guarantee a component in another state has been created at the time you are trying to set it. It's hard to say for sure without seeing your code, but I'm guessing that is the issue based on your error.
You'll, basically, have to create your own method of deferred value setting. So, when you try to set it do something like this:
if(Latest_News_Display){
Latest_News_Display.x = 10
} else {
cachedLatest_News_DisplayX = 10
}
Then listen to the currentStateChange event and set the new value then:
protected function onCurrentStateChange(event:StateChangeEvent):void{
Latest_News_Display.x = cachedLatest_News_DisplayX
}
I'll also add that, based on the bolded items in your question that it appears you are trying to access a state by name Latest_News. If you create a local variable pointed at a specific state, you can do this. But, if you're using MXML then you probably didn't. Even so, a state is just, basically, an array of overrides you wouldn't be able to access components in that state directly.