Does HSQLDB support replication or clustering. I found an age old experimental feature for HSQLDB replication.
see http://www.jgroups.org/hsqldbr.html and www.jgroups.org/hsqldbr/design.pdf
but it seems this feature never made its way to hsqldb.
Does anyone know what is the current status of this feature and whether or not hsqldb support replication/clustering?
Edit: We used HA-JDBC and found it to be quite useful for our need. Initially, I thought HA-JDBC is a dead project because there were no releases for the past 3 years, but it being maintained in a SVN repository and new features are being added in GIT repository.
This feature is supported by add-ons C-JDBC and HA-JDBC as listed on this page. Replication and clustering has many variations and these software package cover different feature sets.
http://hsqldb.org/web/hsqlUsing.html
Related
I am working on Power Designer 16.1, the repository is installed on a Linux server.
I have an issue with the repository sometimes dropping my models, in most cases I am able to check-in the models to the repository and check-out correctly, but sometimes after I correctly check-in a model it seems that it is being deleted from the repository.
I am not sure but I think the problem may occur when two (or more) people tries to check-in the same model at the same time (or overlapping), and that causes the model to disappear from the repository.
Any idea or workaround to fix this?
Does reading logs of PowerDesigner can help to clarify the reason?
Maybe repository has it's own server logs?
First make sure you upgrade to the latest version. They fix tons of bugs in each patch, and a lot of them have to do with the repository. It is very likely that this will fix it.
But we still found it best to have ONE designated person do check-in on models, to avoid strange issues.
If you use any replication between models, the repository will act even stranger than it already does, so if you can, try removing replicating properties from your models.
Apart from that, we make daily database backups of the repository and we sometimes have to use them too.
Another thing that may help: in the PowerDesigner Repository Administration menu you can select to rebuild indexes, if you have the logon/password for the account that installed the repository. Rebuilding indexes has solved several nasty prob
And now a bit off-topic: in my experience (working with the repository for 3+ years now), it has always been very buggy. Even with the highest patch level installed we have lots and lots of weird issues. This only gets worse when you have 2 repositories in order to test a new release of PowerDesigner. PowerDesigner's habit of hardcoding ID's into models make this very problematic.
I know someone who is often hired by SAP as PowerDesigner Instructor. His recommendation is to stay away from the repository and use Git. It has always been a badly integrated add-on with questionable support. The datamodel for the repository is horrible (which is quite ironic) and it seems that foreign keys and relational integrity are foreign concepts to it.
So we are now in the process of moving off the repository and onto TFS. All PowerDesigner models are XML, so TFS or Subversion or Git etc. will do nicely (but we like the locking of TFS/Subversion for this). Yes, we will have to forget about the nice display of changes, but frankly, having a robust version management instead of the buggy and model-destroying repository is worth it.
I work in a shop that's adopted TFS for source control. We're happy with the integration in VS and the other features it offers, so it's likely we're not going to switch to another platform. However, features for team collaboration and documentation are lacking compared to other solutions, most notably SVN + Trac.
Has someone been able to integrate TFS 2010 with TRAC?
EDIT:
It's been asked that I clarify my intent here. It's very simple. I'm just asking if the TRAC project management and bug/tracking system can be used in conjunction with TFS. And, if so, what would it take?
Remember, I'm not looking for a Sharepoint solution--I've already got that. I'm asking if it's possible that TRAC and TFS can get along.
(Long rambling clarification on what I'm looking to get out of TRAC removed. The question is simply "Can TRAC work with TFS?")
Not so much of a trouble a the Trac side. There is FOSS everywhere, a lot of modularity and flexibility. No quite the same at the other side. I've read about the trouble even with one-time migration from SVN to TFS. Despite the source is all open and well documented, there no evidence of good support, that should tell you much about the chance for getting even more - constant synchronization.
Facts: MS SQL server is the base for TFS. No connector available for MS SQL server as a Trac db backend, although there are several python bindings to MS SQL server available, or the option to connect via ODBC. But just an option, nothing ready AFAIK.
I'm not aware of any well documented open TFS API as foundation for migration and integration. And I'm not convinced this will ever change. At Redmond (Microsoft) they are reportedly only considering what seems important to themselves: "helping customers with IBM Rational ClearCase and ClearQuest tools." And most probably it this behavior will persist and SVN/Trac keeps very low on the ToDo for them.
[Edit2]
While TFS has some support for bidirectional communication, these scenarios are not recommended. It mostly aims at integration, read: sucking information in, not communicating with other information systems like Trac.
[Edit]
Just for sub-task of repository browsing you could try to write code to push a duplicate of changes to another (SQLite|MySQL|PostgreSQL) repo that Trac supports right now. But I consider this is rather wasteful and ugly, and fact remains, that it's hard, if possible at all, to do the same tracking without such big code duplication. Ultimately, if you want to live without the actual check-in source changes you must at the very least send information about the meta-data like resource ID's (for link generation) to find the data in TFS.
I'm looking into that right now. So take the following as half-educated advise to the best of my knowledge and feel free to correct/discuss.
Our company is using ClearCase for version control and as a medium to exchange code with sibling companies.
Some of these sites are planning to switch from CC to sub version.
Our site management is unenthusiastic about replacing our version control system.
A possible compromise is using the CM bridge by Clearvision, but I found next to zero customers reviews about this product.
I as especially interested the risks involved with using it.
Can anyone point out any such risks or possible difficulties associated with this product ?
All migration we did are from ClearCase to Subversion, without bridge or synchronization after the migration: it is simply not worth it.
The major risk for those migrations is to blindly import all the history, all the branches (including the ones locked and/or obsolete??? The documentation -- administration guide -- never mentions those kind of objects), all the labels (including the ones set only on 3 files, as opposed to full baselines set on all the files of an UCM component)
The differences are too important between the file-atomic operations of ClearCase and the repository-wide commits from Subversion to hope getting a complete mirror.
That also leads to the second major risk: adapting and evolving the set of practices around the VCS: having two in parallel means more work and a more error-prone environment to deal with two VCS.
As it is included in the license (according to SAP) we would prefer using Solution Manager over other tools, for the entire life-cycle of software development. Or is it highly recommended to use specific tools for the particular processes like Test Management? Any opinions?
in general before answering this question, please be aware that SAP will bring out a new support model and the features and functions available in your SolMan installation will differ according to the support you requested from SAP. If you stick to the Enterprise Support you will (nearly) get every functionality, for Standard Support you well get less and a lot of features will not be included. At the moment, SolMan 7.10 is in Ramp Up Phase and 7.20 will be released in 2011. Due to the fact, that SAP changes the kernel of the Solution Manager Stack, which is apparently CRM from 5.0 to 7.0 you should keep in mind, that any functionality you implement in your current SolMan will lead to high migration efforts.
Apart from this, if you look at the Enterprise version, my experience is that not all features are rather good and suitable. It also depends on the organization you are working in. The SAP tools focus only on SAP, so if you are working in an environment where non-SAP Java has an important part I would look for different tools. If you look into the change management (ChaRM), it is suitable for small landscapes and for big ones only with some effort. Here you should also consider at least to have a look at different technologies and tools. From my point, there are some things like monitoring, job scheduling etc. which are quite good, but for the more general application lifecycle management tools you should at least take other options into account.
My development group uses Visual Source Safe for version control; this choice was originally made due to cost and its tight integration with Visual Studio.
As our repository has grown Source Safe has really started to show its limitations and we are considering moving to another solution. Up for discussion are Team Foundation Server, Subversion, Git, and Mercurial.
We are largely a data shop, so another major factor for us is being able to easily version SQL Server 2005/2008 projects. This is one of the benefits of using Source Safe, and also of Team Foundation Server - the integration with Microsoft SQL Server Management Studio.
I'm wondering if anyone has had experience versioning SQL Server with Subversion, Git, or Mercurial and can provide some solid pros/cons for each of these systems, as well as how you went about implementing them.
My honest answer is don't do any integration with your database tooling and SCM if you can avoid it. Use the filesystem where possible. It's another layer of integration which is going to be a pain. Small separate tools are better than a behemoth.
We use Subversion and SQL 2005 together in the following manor:
We use TortoiseSVN only. No VS/SSMS integration at all.
We have a principle of "automate everything", so we never rely on GUI tools to do work.
We keep all scripts inside SVN along with the code. The code, schema and scripts are versioned together.
Schema changes are numbered in order of application i.e. 000-create-table-users.sql. We write down the maximum script number deployed in each environment. Each script performs a migration to the next database r number. When we deploy, we check out the source and run all scripts from the last version number to the highest number.
Any non-schema scripts (sprocs/views) are idempotent (can be executed any number of times with the same result). They are applied via a nant plugin we wrote. These are replaced every time we deploy. Don't forget to refresh your views!
We avoid any scripts where possible anyway as we use NHibernate so there are less problems with script versioning anyway.
From this structure, we can re-create the environment and database at any point in time on any machine which is important.
We do NOT use it for unit testing however - we rely on the NHibernate schema generation to do this on top of an SQLite database.
The only negative point we've encountered has been making sure that developers adhere to the process. Herding cats is a very appropriate description.
Visual Studio Team System 2008 Database Edition (codename "DataDude") is what you need.
It allows you to version your database objects in ways that will blow your mind. (eg upgrade a customer site to a specific version, or rollback to a previous version without destroying any data).
Check out the features at Gert Drapers' blog, starting with this post.
Or if you prefer a podcast, listen to DotNetRocks with Chris Sells in show 494.
I don't know whether you're limited to TFS for source control, when using DataDude -- but it is the undeservedly "underhyped" member of the Visual Studio family.
This might be a useful tool for you:
http://www.liquibase.org/
It's designed so that it's easy to version control in any system, and manages your upgrade scripts in a sane way.
Git and Mercurial are the only ones you should consider IMHO, the other 2 are too old-fashioned. Modern SCMs should treat branches like git does.
For git vs. mercurial comparisons see:
http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/, http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn.
I have no past experience with SSMS SCM integration though, but AFAIK neither of the systems mentioned (except from TFS) have one. I wouldn't call it a disadvantage tho - git GUI for example is a pretty handy tool, which you'll find more enjoyable than such an integration. This is at least my case when moving from SVN (with VS integration using Ankh) to Git (with no integration at all)...
Mercurial has VS integration with VisualHG, if you think DVCS is the way to go. We use that for C++/C# projects in our shop, and it works well enough. (OTOH, I've never used any "full" integration, so I'm happy to work with the explorer extension and/or command-line for detailed VC work.)
We've now added VSS support to SQL Source Control, which integrates with SSMS to provide fully integrated source control for database development. To try this out, please visit:
http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265
TFS is missing a few features of VSS, notably keyword expansion. If you don't embed revision keyword info within your source files, then it should not be a concern.
There are potentially quite a number of alternatives - SQL Server Management Studio (SSMS) supports integration with any Microsoft Source Code Control Interface MSSCCI Provider. So you can broaden the search to source control systems that feature an MSSCCI compatible provider.
In SSMS, Check out Tools -> Options -> Source Control to see what provider plug-ins are installed on your system.
For example, Team Foundation Server's integration with SQL Management Studio is courtesy of the TFS MSSCCI Provider. I think there's a provider for CVS/Subversion ("Aigenta Unified SCC") and so on.
As to a pros/cons list, I think provided there's a compatible provider, you can open the question up to a wider audience. My main experience is with VSS, TFS and Subversion. It really comes down to your team, and environment. Can you elaborate more on your environment?
E.g.
would you be interested in establishing CI (continuous integration)?
automated builds/automated versioning?
support for multiple environments?
configuration management?
what team size do you have? likely to have lots of merges/branching etc?
do you have a bug tracking system in place already (you get work items/bug tracking as part of a TFS roll out)?