In AccuRev, is there a way to change the comment I provided for a transaction?
No, you can't change a comment that's already been submitted, that would violate AccuRev's Timesafe Architecture. In the future, we will potentially be adding the capability to "amend" the comment while retaining the previous history. This isn't there yet, but does already have an existing enhancement request. Hope this info helps you out...
Cheers,
~James
Related
It might be super obvious but no one bothered clarifying what or who is actually creating/writing the changesets for liquibase. I read more than a dozen articles related to changesets in liquibase and while I now understand how it works I still wonder if these changesets are generated somewhere by Liquibase ? Or are users supposed to write them by hand ?
And do we agree that the CHANGELOGTABLE, is populated from doing a liquibase update by reading the already existing changesets ? Not the other way around ?
And do we also agree that liquibase doesn't track schema changes, it just computes the desired state of a DB from the changesets ?
Thanks
Edit: I asked many questions, but ultimately I'm just looking for an answer to the title and somehow understand properly how liquibase works.
You write the changeset. And since you can write changesets in sql, its just you writing the database scripts your application needs.
Yes, the DATABASECHANGELOG table is the audit log that gets written after a liquibase update that shows what changesets got executed.
I would recommend taking the fundamentals course provided for free at Liquibase University that covers these very basic concepts. Without it, it will be much harder to be successful using Liquibase. My experience: You can pretty much finish the course in one sitting or maybe an hour each day for a few days.
Any reason why Liquibase's addNotNullConstraint doesn't have an attribute initiallyDeferred?
addForeignKeyConstraint and addUniqueConstraint both have an attribute initiallyDeferred.
I think this is just a missing feature. Liquibase has very few people contributing code, so sometimes things just aren't done yet. My company (Datical) has been making efforts to improve that, but we still rely very heavily on the users of Liquibase to point out where there are shortcomings.
I have created a jira ticket (CORE-3024) to track this.
I've encountered the raw_native_types in a tlb import statement and I'm unclear of what the benefit of this attribute is. I've read the MSDN description for this (http://msdn.microsoft.com/en-us/library/8etzzkb6%28v=vs.71%29.aspx#_predir_raw_native_types) but it hasn't helped clearing it up for me. Can someone help explain it to me?
Thanks.
The intention defines the benefit. If one really doesn't want to use _bstr_t or _variant_t because, who knows, one abominates them (not that uncommon), or one doesn't trust the compiler to actually do a good job at keeping them alive, or one already uses other smart wrappers, or one really likes to explicitly call SysFreeString and VariantClear, then one specifies raw_native_types.
Everyone:
I've just recently finished implementing a "Soft Deleting" mechanism for my database driven web product using NHibernate. I followed the tutorial here for creating a SoftDeleteListener and it works like a charm, Kudos to the Gabriel Schenker who wrote that very good tutorial.
So, what's the problem? Well, I updated his code for the SoftDeleteListener I've implemented, and I tested it and all seems well. However, when I use a code template from a third party, I ALWAYS want to understand completely what every line of code is doing. In this case, however, I've searched and searched but I cannot find any documentation on the functions of the CascadeBeforeDelete and the CascadeAfterDelete methods! I can pretty much infer that they are doing some sort of foreign key cascading deletion functions, but the documentation on what exactly they are doing is nowhere to be found.
Can someone please point me to the proper documentation for these methods? Or, if none exists, could you kindly explain them to me?
Thanks in advance.
There's no documentation for those methods.
What you can do is get the NH sources and see how it's used in the code.
After Diego's suggestion, I've taken a quick look at the NHibernate sources for these files and, from the comment blocks in the source code, have determined their functions:
CascadeBeforeDelete - Cascades the delete call to all collections of that object before the object is deleted.
CascadeAfterDelete - Cascades the delete call to all many-to-one relationships to the object after the parent has been deleted
This was just taken from the comment directly, and I really don't have the time to thoroughly investigate these methods functions (tight deadlines keep me awake at night). If anyone has any more information on these methods they would like to share it would be greatly appreciated. Thanks.
In essence this is a followup of this question. I'm beginning to feel that I should give up the whole idea, but I'll give it one more shot.
What I want is pretty much like a DB transaction. It should track my changes to the DB and then in the end allow me to either commit or rollback them. If I insert an object, I should get it back in my next (appropriate) SELECT query. If I delete it, future SELECT queries should not return it. Etc.
But there is one catch - this transaction would be very long running. It would start when the user opened a form (I'm talking about Windows Forms here), and the commit/rollback would be when the user closed it(with OK/Cancel). So it could take anywhere between seconds and days. This requirement rules out a standard DB transaction because that would lock the tables/rows it touched, and other users wouldn't be able to use the system. Also the transaction should not commit ANY changes to the DB until it was really committed. So if one user makes some changes, others don't see them until OK button is hit. This prevents errors in case the computer crashes or is disconnected from the network.
I'm quite OK if the solution puts constraints on my model (I'm using MSSQL 2008, btw). I can design the DB/code any way I like. I'm also fine with the idea that a commit could fail because someone already modified one of the objects my transaction touched.
Is there anything like this? I looked at NHibernate.Burrow, but I'm not sure that that's the thing I want.
Added: It's the very beginning of the project so I'm not tied to NHibernate. I started out with it but I can still change easily.
As far as I can judge, DataObjects.Net supports exactly this concept via DisconnectedState. The feature is very new (released just few weeks ago), its preliminary documentation is here. WPF sample for DataObjects.Net uses it for UI transactions.
I'm not sure if it is mentioned there, but DisconnectedState, as well as its OperationLog can be serialized. So its cached state can survive even application restarts.
I don't think anyone will implement this in the NHibernate core, because nobody will use it. Viewmodel is not the same model as domain model.
This is not a direct answer to your question, but this is the sort of thing that WWF (gotta love the name) was set out to solve (not that it did so at least by v 3.5).
If you're still following this, Ayende Rahien has an article in MSDN magazine http://msdn.microsoft.com/en-us/magazine/ee819139.aspx about the session per form/presenter approach. Also take a look at chapter 5 of the NHibernate book http://manning.com/kuate/ (sample chapter available), the one on transactions and conversations.
As long as you delay the flush/transaction till the ok button is pressed, it should work (depending on the flush mode). But complete isolation is a difficult ask because your session will be able to access data that has been committed by other sessions when dealing with multiple entities. You will have to think about handling such issues.
As an aside, how would you deal with this situation if you don't use NHibernate?
EclipseLink has limited supported for such a beast. They call it "Conforming" and they implemented it in the "unit of work" context.