Each time I create a new Target Milestone in Bugzilla, I have a set of bugs that I need to create and associate with that target (these are essentially all the same, and could be based on some kind of template).
These bugs represent a set of tasks that must be performed as part of every milestone.
Is there a way to auto-create a set of bugs for each milestone that I create?
You could create a Bugzilla extension that hooks object_end_of_create http://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/Hook.html#object_end_of_create and specifically looks for the milestone object then create the needed bugs.
Related
In an application we inherited (Winforms) based on DevExpress, an object of type UnitOfWork is used to keep track and save multiples records in the database.
Usually around 100 objects can be saved in the database on a button click using the method UnitOfWork.CommitChanges();
The table where the records are inserted has an unique constraint on a column.
It might happen that different users try to treat the same entities and to try to enter in that table the same value in the unique column.
So definitively before using UnitOfWork.CommitChanges() we should test if one or more values do not exist already in the database.
What would be the best approach to test if one or more objects are not already in the database before calling UnitOfWork.CommitChanges(), so that we can surely warn the user on his validation?
Thank you
It's not really the DevExpress way of working, see the help topic on auto-generated keys.
However, since you have inherited the code, you could use UnitOfWork.GetObjectsToSave() to obtain an ICollection of the IXPObjects you are about to commit. From this collection you could generate a list of potential key conflicts. Then you could use UnitOfWork.ExecuteScalar() to run a direct SQL command to determine if there are conflicts and resolve them.
The UnitOfWork.CommitChanges() calls CommitTransaction, so you could perform this check in one of the UnitOfWork events such as UnitOfWork.BeforeCommitTransaction.
As with everything DevExpress, your best support option is the DevExpress Support Center.
The functionality you ask for is not possible to implement in a multiuser system. As every user (necessarily) works in his own database transaction, there is always a chance for a user to insert a datarow with a key that another user inserted right before. You could only avoid this by employing database mechanisms like autogenerated keys. But I think this is not applicable for you.
So I suggest to catch the exception thrown by commitChanges and act upon it.
I often write code that has a dependency on a database entity. I want to minimize the coupling between those different systems (or make it explicit and robust).
Example: I have a dropdown list of error categories, the users can define new categories, but one category is special in that errors belonging to it get an extra input field. So the system needs to know when the user has selected the special category and this special category is not allowed to just disappear.
How would you handle that special category? Would you match on on the category name or id? would you put the entity in the migration or have your code regenerate it as needed? Do you omit it from the database and have it only exist in your code? I find myself picking new solutions every time this problem presents itself, but I'm never quite satisfied with them.
Has anyone found a satisfactory solution? What drawbacks have you found and how have you mitigated them?
I dislike special case code, so I would design it to all be in the data model. The database would get a can delete field, and a has special entry field with some way to describe what that special input is. I would also try to make sure that I didn't over design the special input stuff since there is only this case so far.
What is the standard guidelines for activity creation?
In our team, all team members are creating activities by their own.
It is not being assigned by team leader. Is it possible to create an activity by team leader then assign it to members?
How to achieve it?
Two ways you could go.
ClearCase (stand alone):
A trigger can enforce, the activity or the naming of the activity but this can require intial development of trigger and script & also the maitenance. You may also go part way in which you enforce the prefix to be ENH_* or DEF_* or CR_*. You can even check to see if total activity is in a list of strings you specify...limited to your need.
Alternative (ClearCase with integration):
What you may be looking for is a higher level order, I had created such a system with ClearCase integrated to ClearQuest. Developers are assigned "WorkRequests" (e.g. Defects / Enhancements) These can be directly assigned, tracked and added to builds.
In essence you use the record ID acts node that holds all activities checked in by developer. You can report/slice/dice with activitis and checkin refs as you want)
In this model you control the assigned record not the activity (but they can be the same! ie. raised records with known activties in advance and assign them.)
Regards
Jim2
No, the usual practice is that usually one would select an activity he/she created when checking in new versions.
The "setactivity" doesn't list any restriction in term of Identity when selecting the activity to use.
An activity is here to group some tightly linked changes together, changes being new versions on files or directories for a given component on a given stream.
There is no real "standard guidelines" except to keep linked changes together.
You could prevent the creation of activity (except for a project manager) with a pre-op trigger though.
I suppose another trigger might be able to enforce the selection of an activity only by a specific resource, emulating that way the "assignment" process.
But I rarely seen that implemented (or only when use with a link with ClearQuest).
I'm building an Event Registration site. For any given event, we'll have a handful of items to choose from. I have a table for these items. For each event we might have special options for users. For example, for one of the events new users get to buy an item which is not available to other users. This may not apply to all the events. For other events we might have some other restriction on items. I will obviously be checking this programmatically on application side. I would like to though, set up a column containing flag in the items table. But I don't find it feasible because this condition may only apply to one particular event. I don't want all the future items to have this column. What is a good approach to take in such a situation? Should I create a special "restrictions" table and just do a join? How would I handle this on the application side?
Yes, you are going to need an additional table with the list of items that have special rules.
It sounds like the 'special options' idea is still evolving, so it's probably too early to know whether to think of it as containing 'restrictions' or 'bonuses'
And of course you'll probably need another table which maps items to particular groups of users.
General advice in this sort of situation: you should do something simple until the spec gets at least semi-frozen. I've just gone through it myself: the marketing guys had all kinds of ideas about special deals and discounts. If I had taken the time to build the perfect engine, it would have gotten tossed a month later when they changed direction.
I'm a J2EE developer & we are using hibernate mapping with a PostgreSQL database.
We have to keep track of any changes occurs in the database, in others words all previous & current values of any field should be saved. Each field can be any type (bytea, int, char...)
With a simple table it is easy but we a graph of objects things are more difficult.
So we have, speaking in a UML point of view, a graph of objects to store in the database with every changes & the user.
Any idea or pattern how to do that?
A common way to do this is by storing versions of objects.
If add a "version" and a "deleted" field to each table that you want to store an audit trail on, then instead of doing normal updates and deletes, follow these rules:
Insert - Set the version number to 0 and insert as normal.
Update - Increment the version number and do an insert instead.
Delete - Increment the version number, set the deleted field to true and do an insert instead.
Retrieve - Get the record with the highest version number and return that.
If you follow this pattern, every time you update you will create a new record rather than overwriting the old data, so you will always be able to track back and see all the old objects.
This will work exactly the same for graphs of objects, just add the new fields to each table within the object graph, and handle each insert/update/delete for each table as described above.
If you need to know which user made the modification, you just add a "ModifiedBy" field as well.
(You can either do this processing in your DA layer code, or if you prefer you can use database triggers to catch your update/delete/retrieve calls and re-process them following the rules.)
Obviously, you need to consider space requirements, as every single update will result in a fully new record. If your application is update heavy, you are going to generate a lot of data. It's common to also include a "last modified time" fields so you can process the database off line and delete data older than required.
Current RDBMS implementations are not very good at handling temporal data. That's one reason why maintaining separate journalling tables through triggers is the usual approach. (The other is that audit trails frequently have different use cases to regular data, and having them in separate tables makes it easier to manage access to them). Oracle does a pretty slick job of hiding the plumbing in its Total Recall product, but being Oracle it charges $$$ for this.
Scott Bailey has published a presentation on temporal data in PostgreSQL. Alas it won't help you right now but it seems like some features planned for 8.5 and 8.6 will enable the transparent storage of time-related data. Find out more.