I'd like to refactor some of my sagas and messages and move them to a new namespace.
I can't clear out the existing worker queues and need to have the old saga/messages still work until they are all gone.
I won't be changing any behaviour of the saga/messages just the namespace, is there an easy way to bulk update these so that the old saga/messages can continue to process correctly.
What things do I need to worry about here, is it possible to do this?
I'm not sure if there's any way you can blanket update all the in-flight saga instances. I imagine you might be able to with some Raven-fu (or SQL if you're using that).
The problem is that NServiceBus uses the fully qualified name of the message type to identify it for routing purposes, so it's a complex problem and something you'd want to get right first time.
In effect, what you're talking about doing is introducing a whole load of new messages into your architecture. It may be safer to introduce the change in parallel, allow all in-flight saga instances to complete, and then decommission the obsolete - and now unused - bits.
NSB documentation has this to say about handling breaking changes, though nothing specific to in-flight sagas...
When there are significant changes in a message type, such as adding
or removing property, changing the property type, etc. the upgrade
process should consist of the following steps:
Update contract to the new version.
Update senders to use the new contract version. Ensure changes are visible for receivers, such as: Decorate the existing property with
Obsolete attribute with a warning when removing or renaming
properties.
Update receivers to handle the new contract version. Make sure the new properties are handled correctly, e.g. instead of relying on .NET
to set the default value for int Age = 1, it's better to use nullable
types and represent missing values as null.
When all senders and receivers are updated and in-flight messages in the old format have been handled, obsolete the properties and throw an
error, or simply remove them.
Related
This is about an API handling the validation during saving an object. Which means that the front-end client sends a request to the API to a specific end point, then on the back-end the API creates a new object if the right conditions are meet.
Right now the regular method that we use is that the models has a ruleset for each fields and then the validation is invoked when the save function is invoked, but technically the validation is done right before the object is saved into the database.
Then during today's code review I came across a solution which I wasn't sure if it's a good practice or not. And it was about that the front-end must send a specific parameter to the API every time. This is because other APIs are using our API as well, and we needed to know if the request was sent as and API request or a browser request. If this parameter is present then we want to execute an extra validation function on a specific field.
(1)If I would have to implement it, then I would check the incoming parameter in the service handler or in the controller level, and if I got one, I would invoke the validation right away, and if it fails I would throw an error.
(2)The implementation I saw however adds an extra variable to the model, and sets the model variable when there is an incoming parameter, then validates only when the save function is invoked on the object(which first validates the ruleset defined on the object fields, then saves the object into the database)
So my problem with (2) is that the object now grown bigger with an extra variable that is only related to a specific event. So I would say it's better to implement (1). But (2) also has an advantage, and that is when you create the object on different end point by parsing the parameters, then the validation will work there as well, even if the developer forget to update the code there.
Now this may seems like a silly question because, why would I care about just 1 extra variable, but this is like a bedrock of something good or bad. So if I say this is ok, then from now on the models will start growing with extra variables that are only related to specific events, which I think should be handled on the controller/service handler level. On the other hand the code would be more reliable if it's not the developer who should remember all the 6712537 functionalities and keep them in mind when makes some changes somewhere. Let's say all the devs will get heart attack tomorrow from the excitement of an amazing discovery, and a new developer has to work on the project while he doesn't know about these small details, and then he has to change something on the code that is related to this functionality - so that new feature should be supported by this old one as well.
So my question is if is there any good practice on this, and what do you think what would be the best approach?
So I spent some time on thinking on the solution, and I think the best is to have an array of acceptable trigger variables in the model class. Then when the parameters are passed to the model on the controller level, then the loader function can be modified that it takes the trigger variables from the parameters and save it in the model's associative array variable that stores the trigger variables.
By default this array is empty, and it doesn't matter how much new variables are needed to be created, it will only contain the necessary ones when those are used.
Then of course the loader function needs to be modified in a way that it can filter out the non trigger variables as well as it is done for the regular fields, and there can be even a rule set of validation on the trigger variables if necessary.
So this solves the problem with overgrowing the object with unnecessary variables and the centralized validation part, because now the validation can be always done in the model instead of the controller.
And since the loader function is modified to store the trigger variables in the model's trigger variables array variable, the developer never has to remember that this functionality was created. Which is good, because in the future when he creates a new related function or end point that should handle object creation, he will not miss it to validate it against the old functionality, because the the loader function that he modified in the past like this will handle it for him.
It needs to be noted tho, that since the loader function doesn't differentiate between the parameters, and where to load them other then checking the names of the parameters with the filter functions, these parameter names should be identical from each other, otherwise a buggy functionality can be created accidentally. Like if you forget that a model attribute with the same name was used, then you can accidentally trigger an event that was programmed to be triggered if the trigger variable with the same name is present. However this can be solved by prefixing the trigger variables for example.
Say I have a table for machines, and one of the columns is called status. This can be either active, inactive, or discarded. A discarded machine is no longer useful and it only used for transaction purposes.
Assume now I want to discard a machine. Since this is an entry update, RESTfully, this would be a PUT request to /machines/:id. However, since this is a very special kind of an update, there could be other operations that would occur as well (for instance, remove any assigned users and what not).
So should this be more like a POST to /machines/:id/discard?
From a strict REST perspective, have you considered implementing a PATCH? In this manner, you can have it update just that status field and then also tie it in to updating everything else that is necessary?
References:
https://www.mnot.net/blog/2012/09/05/patch
http://jasonsirota.com/rest-partial-updates-use-post-put-or-patch
I think the most generic way would be to POST a Machine object with { status: 'discarded' } to /machines/:id/.
Personally, I'd prefer the /machines/:id/discard approach, though. It might not be exactly in accordance with the spec, but it's more clear and easier to filter. For example, some users might be allowed to update a machine but not "archive" it.
Personally I think post should be used when the resource Id is either unknown or not relevant to the update being made.
This would make put the method I would use especially since you have other status types that will also need to be updated
path
/machines/id
Message body
{"status":"discarded"}
Two views in my application need to load same information when restoring state. My idea was, to avoid saving it twice, to have one view create another in init orcreatePartControl if it wasn't created yet. However,
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().showView(...)
doesn't work there, as getActivePage() returns null. Is it possible to work around this?
Delegate to a manager or service to load/maintain/save the shared state. That will ensure the first access initializes your information. When the view is instantiated just go to the manager and retrieve the information. If the user never instantiates your view, then you never had to do the extra work.
In the general case, you can't create/instantiate one view while creating/activating another view. Eclipse won't allow it, and will generate ERRORs in the error log.
EDIT:
3 standard persistence patterns I've seen used (and/or misused :-) are:
1) Have your plugin get its state location and simply serialize you state out there. (location provided for free if you subclass org.eclipse.core.runtime.Plugin) You can do it in your activator stop(BundleContext) method. You can uses classes like org.eclipse.ui.XMLMemento to serialize to/from XML if you don't already have a solution.
2) if you subclass org.eclipse.ui.plugin.AbstractUIPlugin you can use org.eclipse.ui.plugin.AbstractUIPlugin.getDialogSettings() to store your state. Potentially a little bulky as you would have to keep it up to date.
3) have your common manager update a preference, potentially using another serialization technique.
I have a case where one of the columns on the database is generated using a trigger because of a specific way we generate this value which I can't change. If I in my mapping in NHibernate sets the property to generated=insert, it works like a charm, where NHibernate inserts the row without the generated property, and afterwards does a select to pull the value from the database.
But I also have cases where I want to be able to set the property explicitly (the trigger is built to only set the column if it's not set). But I can't get NHibernate to allow me to do this. When it's set to generated=insert, it will always ignore the property I set in my object. So I really want to be able to somehow tell NHibernate that when the property is "untouched"/null, act as property is generated, but if set, don't.
Is it possible to configure NHibernate this way somehow?
I don't think you can achieve this through configuration. However, you can simply call ISession.Refresh(myObject) after an insert to force it to go back to the database and refresh the object.
Documentation for the generated property states (emphasis mine):
Properties marked as generated must additionally be non-insertable and non-updateable. Only Section 5.1.7, “version (optional)”, Section 5.1.8, “timestamp (optional)”, and Section 5.1.9, “property” can be marked as generated.
Is it a property that can be set as nullable in your domain model so on the initial insert nothing goes into it and your trigger still thinks it's untouched?
My domain model allows for null insertion of the value. And my trigger is made to only set the column if null inserted. What I'm trying to achieve is to at runtime decide, wether or not NHibernate should handle it as a generated property.
But from what I can understand, NHibernate does not have this sort of flexibility and somewhat strides against it's configuration structure where it builds a session factory once for multiple uses.
The alternative solution could be to build two session factories, one for each of my scenarios.
The first (where property is generated) is normal usage.
The second (where property is non-generated) is during upload scenarios where I need to maintain the property value in the code.
I'm using FluentNHibernate for the mappings, and since it reflects over my mapping classes, I could set a state during creation of session factories, so when my mapping is being read, I could do an if/else statement based on which session factory is currently being built. This should allow me to achieve both without duplicate configurations, although with two session factories in play instead of one.
I haven't tried it yet, only theory, but it should solve my problem and hopefully others trying to achieve similar.
I'm working on a small application using C++/wxWidgets, where several parts of the GUI need to be updated based on e.g. received UDP datagrams. More specifically, a secondary thread tries to keep a list of available "clients" in the network (which may come and go away) and e.g. corresponding comboboxes in the UI need to be updated to reflect the changes.
The documentation mentions that for this kind of thing EVT_UPDATE_UI would be a good choice. As far as I can understand from the sparse documentation, this event is sent automatically by the system and provides some support for assisted UI change.
However, I'd feel more comfortable using a more direct approach, i.e. where e.g. a window object could register/subscribe to receive notifications (either events or callbacks) upon particular events and another part of the code is sending out these notifications when required. I could do this in C++ using my own code, however I guess if wxWidgets already supports something like that, I should make use of it. However I haven't found anything in that regards.
So, the question is: does wxWidgets support this kind of notification system (or similar alternatives) or would I be best served coding my own?
AFAIK there is nothing directly usable in wxWidgets, but doing it on your own seems easy.
What I would do:
Create a wxEvtHandler-descendent class to hold the list of available "clients" in the network. Let this class have a wxCriticalSection, and use a wxCriticalSectionLocker for that in all methods that add or delete "clients".
Create a worker thread class by inheriting wxThread to handle your UDP datagrams, using blocking calls. The thread should directly call methods of the client list object whenever a client has to be added or removed. In these methods update the list of clients, and ::wxPostEvent() an event to itself (this will execute the whole notification calls in the main GUI thread).
Handle the event in the client list class, and notify all listeners that the list of clients has changed. The observer pattern seems to me a good fit. You could either call a method of all registered listeners directly, or send a wxCommandEvent to them.
Have you tried calling Update() on the widget(s) that change? Once you update the contents of the combo box, call Update(), and the contents should update.