I am adding some 2000 new objects to a DOORS module, I do this by importing a spread sheet with blank IDs, DOORS is supposed to create IDs for those blank rows.
Now the problem is, while i import spreadsheet, DOORS hangs, then when i Kill DOORS process, it anyhow creates IDs, next time when i add a new object, ID number starts from those which are already created but no exist. For some reason i need to continue from my last saved ID. Is there any way I can do this?
several remarks here:
works as designed. As soon as an object is created in any DOORS session, the new absolute number is centrally marked as "used". I think the main reason for this feature is the possibility to work in shared mode. If there were a different design, you would get into trouble as soon as two developers work on the module at the same time.
are you sure that DOORS really hangs? Perhaps it is just not yet finished, at least you can see that the objects are really created. Note that depending on how the script is written that you use for import, the number of imports per second might decrease significantly for bigger files
You should NEVER give any meaning to the absolute number other than uniqueness (perhaps QSS should have used timestamps or UUIDS instead of integers for their absolute numbers when they designed DOORS, this would make the situation clearer). You will have to rework “some reasons” . Perhaps you use a different mechanism to assign your own ID mechanism or you have to evaluate whether the requirement “generate consecutive numbers without gaps” is really necessary.
I have the following case.
A reservation, this reservation be canceled, it can be newly created it can be Confirmed it can be rejected.
There might be different reasons for cancelation. Lets say the reservation has expired, or it may have not been processed within certain timelimit or some other reason.
In order for a reservation to be confirmed a multiple sub - transactions should be performed. This mean that there is a flow within the Confirmation itself. The solution my team came with is some sort of work table holding many different statuses. Which is fine. I felt the need to uniquely identify the state of a reservation by declaring a field ReservationStatus that depicts certain variation of statuses that are already defined in the table. In this case the Reservation status would be NEW,CONFIRMED,CANCELED,REJECTED. Each state will depict certain variation of statuses in the work table.
My team was convinced that this is adding additional complexity. I think this is the opposite it simplifyes the flow. It also declares a natural discriminator and polymorphism. We are supposed to use Queues and asynchroneus processes.
How can I actualy jsutify that we should have such column it apears the arguments I already mentioned were not enough and deep down inside I know I am right :)?
Wanted this to be a comment but it came out too long so here it goes.
#AlexandarPetrov I would add the following questions:
Do all the Statuses concretely represent every State a Reservation could have?
Are there clear rules for all Status migration paths? For e.g. Expired -> CONFIRMED and so forth.
Do you need to model the state changes? And is it a finite state machine?
I'd personally expose the status field but only if it is concrete enough by itself to define state. For e.g. I've seen cases where there are 2 layers of statuses - status and sub-status. In a case like that boundaries are lost and state becomes a complex VO rather than a simple field and state transition rules could become blurry.
Additionally:
For me it seems like Event Sourcing and CQRS could be a good fit for all those Reservations. Especially having in mind the complex flows you mention. Then transitions will be events being applied and the statuses - a simple way to expose state. Tracking status changes separately will also be needless as the Event Stream holds all historical data.
Finally:
How can I actualy jsutify that we should have such column it apears the arguments I already mentioned were not enough and deep down inside I know I am right :)?
Well at the end you can always put your foot down and take responsibility. And if it turns out to be a wrong decision in time - bare the responsibility and admit the mistake.
I need to plan the placement of a set of virtualized functionalities over a set of servers using OptaPlanner. My functionalities needs to be executed in a specific pre-defined order, forming a Service Function Chain.
For example Let's say 2 chains are defined
F1->F2
F1->F2->F3
The goal is to place them on a set of servers while minimizing the costs (bandwidth, CPU, Storage,.. costs)
The examples I see in the OptaPlanner user guide for a set of chained planning entities include the Traveler Salesman Problem (TSP) and VRP, however in theses problems the planning entities do not need to be planned in a specific order.
If the sequence order of the functionalities is given you can just give it a bad score if the planned sequence is not correct.
e.g. (pseudorule)
rule "keepServiceFunctionChainSequence"
when
Functionality($chainId:chainId,$end:end, $orderPos:orderPos)
// find another entity in the same chain with a higher position in the order
// that starts earlier
Functionality(chainId==$chainId, orderPos>$orderPos, start.before($end), $orderPos2)
then
scoreHolder.addHardConstraintMatch(kcontext, $orderPos2-$orderPos);
end
if you have a lot of functionalities to plan and you see too many useless moves it may be smart to make an own move that moves one whole chain at once and keeps the sequence.
I want an opinion when it comes to the number of move selectors in local search. Does adding a new move selector (with a given move type) is more positive than negative in most of the use cases. Meaning does it help the algorithms to more quickly escape from local optima , or does it distract the algorithm more with having the additional move types?
And also is there a way to have control of which move types will be played out more than others ,based on the current state of the solution and the constraint violations that are present?
It's usually better if you're running for longer than a few seconds, as it gives more diversity. The default config only has change and swap moves, so one can argue it needs pillar change, pillar swap, 2opt, ... but that depends on the use case. Knapsack needs the pillar swap for example and vehicle routing needs the 2opt, but vica versa they're useless. I do expect that a future version will recognize the chained var and therefore the default config will include 2opts.
As for controlling the move types: you statically make one move type be selected twice as much as another. Or with the probablistic selector you can even differ it per move instance (although you'll need to be able to cache all moves, so not for big datasets).
But out-of-the-box there's not for dynamically changing the move type based on the state of the solution. This is hyper-heuristics really: if the the best score is unimproved for 100 steps, switch to the second moveSelector, etc. Although it's probably possible to do something similar with multiple solver phases and the unimproved step termination, it will be better once we have out of the box support for hyper-heuristics.
Also note that based on the constraint matches - and soon the indictment map (which is the reverse map of the constraint match total map), we 'll look into Guided Local Search, by selected entities with a higher indictment count (= involved in more constraint breaches) more often than the other entities.
Example case:
We're building a renting service, using SQL Server. Information about items that can be rented is stored in a table. Each item has a state that can be either "Available", "Rented" or "Broken". The different states reside in a lookup table.
ItemState table:
id name
1 'Available'
2 'Rented'
3 'Broken'
Adding to this we have a business rule which states that whenever an item is returned, it's state is changed from "Rented" to "Available".
This could be done with a an update statement like "update Items set state=1 where id=#itemid". In application code we might have an enum that maps to the ItemState id:s. However, these contain hard coded values that could lead to maintenance issues later on. Say if a developer were to change the set of states but forgot to fix the related business logic layer...
What good methods or alternate designs are there for dealing with this type of design issues?
Links to related articles are also appreciated in addition to direct answers.
In my experience this is a case where you actually have to hardcode, preferably by using an Enum which integer values match the id's of your lookup tables. I can't see nothing wrong with saying that "1" is always "Available" and so forth.
Most systems that I've seen hard code the lookup table values and live with it. That's because, in practice, code tables rarely change as much as you think they might. And if they ever do change, you generally need to re-compile any programs that rely on that DDL anyway.
That said, if you want to make the code maintainable (a laudable goal), the best approach would be to externalize the values into a properties file. Then you can edit this file later without having to re-code your entire app.
The limiting factor here is that your app depends for its own internal state on the value you get from the lookup table, so that implies a certain amount of coupling.
For lookups where the app doesn't rely on that code, (for instance, if your code table stores a list of two-letter state codes for use in an address drop-down), then you can lazily load the codes into an object and access them only when needed. But that won't work for what you're doing.
When you have your lookup tables as well as enums defined in the code, then you always have an issue with keeping them in sync. There is not much that can be done here. Both live effectively in two different worlds and are generally unaware of each other.
You may wish to reject using lookup tables and only let your business logic operate these values. In that case you miss the options of relying on referential integrity to back you ap on the data integrity.
The other option is to build up your application in that way that you never need these values in your code. That means moving part of your business logic to the database layer, meaning, putting them in stored procedures and triggers. This will also have the benefit of being agnostic to the client. Anyone can invoke SPs and get assured the data will be kept in the consistence state, consistent with your business logic rules as well.
You'll need to have some predefined value that never changes, be it an integer, a string or something else.
In your case, the numerical value of the state is the state's surrogate PRIMARY KEY which should never change in a well-designed database.
If you're concerned about the consistency, use a CHAR code: A, R or B.
However, you should stick to it as well as to a numerical code so that A always means Available etc.
You database structure should be documented as well as the code is.
The answer depends entirely on the language you're using: solutions for this are not the same in Java, PHP, Smalltalk or even Assembler...
But let me tell you something: while it's true hard coded values are not a great thing, there are times in which you do need them. And this one is pretty much one of them: you need to declare in your code your current knowledge of the business logic, which includes these hard coded states.
So, in this particular case, I would hard code those values.
Don't overdesign it. Before trying to come up with a solution to this problem, you need to figure out if it's even a problem. Can you think of any legit hypothetical scenario where you would change the values in the itemState table? Not just "What if someone changes this table?" but "Someone wants to change this table in X way for Y reason, what effect would that have?". You need to stay realistic.
New state? you add a row, but it doesn't affect the existing ones.
Removing a state? You have to remove the references to it in code anyway.
Changing the id of a state? There is no legit reason to do that.
Changing the name of a state? There is no legit reason to do that.
So there really should be no reason to worry about this. But if you must have this cleanly maintainable in the case of irrational people who randomly decide to change Available to 2 because it just fits their Feng Shui better, make sure all tables are generated via a script which reads these values from a configuration file, and then make sure all code reads constants from that same configuration file. Then you have one definition location and any time you want to change the value you modify that configuration file instead of the DB/code.
I think this is a common problem and a valid concern, that's why I googled and found this article in the first place.
What about creating a public static class to hold all the lookup values, but instead of hard-coding, we initialize these values when the application is loaded and use names to refer them?
In my application, we tried this, it worked. Also you can do some checking, e.g. the number of different possible values of a lookup in code should be the same as in db, if it's not, log/email/etc. But I don't want to manually code this for the status of 40+ biz entities.
Moreover, this can be part of the bigger problem of OR mapping. We're exposed with too much details of the persistence layer, and thus we have to take care of it. With technologies like Entity Framework, we don't need to worry about the "sync" part because it's automated, am I right?
Thanks!
I've used a similar method to what you're describing - a table in the database with values and descriptions (useful for reporting, etc.) and an enum in code. I've handled the synchronization with a comment in code saying something like "these values are taken from table X in database ABC" so that the programmer knows the database needs to be updated. To prevent changes from the database side without the corresponding changes in code I set permissions on the table so that only certain people (who hopefully remember they need to change the code as well) have access.
The values have to be hard-coded, which effectively means that they can't be changed in the database, which means that storing them in the database is redundant.
Therefore, hard-code them and don't have a lookup table in the database. Instead store the items state directly in the items table.
You can structure your database so that your application doesn't actually have to care about the codes themselves, but rather the business rules behind them.
I have done both of the following:
Do one or more of your codes have a certain characteristic, such as IsAvailable, that the application cares about? If so, add it as a flag column to the code table, where those that match are set to true (or your DB's equivalent), and those that don't are set to false.
Do you need to use a specific, single code under a certain condition? You can create a singleton table, named something like EnvironmentSettings, with a column such as ItemStateIdOnReturn that's a foreign key to the ItemState table.
If I wanted to avoid declaring an enum in the application, I would use #2 to address the example in the question.
Whether you take this approach depends on your application's priorities. This type of structure comes at the cost of additional development and lookup overhead. Plus, if every individual code comes with its own business rules, then it's not practical to create one new column per required code.
But, it may be worthwhile if you don't want to worry about synchronizing your application with the contents of a code table.