In upgrading from SCDF 1.1.1.RELEASE to 1.2.4.RELEASE, are there any database schema changes that I would need to be concerned about?
Specifically, if I'm already running SCDF 1.1.1.RELEASE on a Pivotal Cloudfoundry platform, and using a MySQL service tile as the underlying database, will the stream, app, and task metadata that is already in the database translate readily to SCDF upgraded to 1.2.4.RELEASE?
What other potential concerns might I need to take a close look at as I plan to upgrade?
Yes, as documented on the official docs: https://docs.spring.io/spring-cloud-dataflow/docs/1.2.3.RELEASE/reference/htmlsingle/#configuration-rdbms
Apart from the migration-script, there shouldn't be any other concerns wrt upgrade. At least in 1.1 -> 1.2, there's simply a case-conversion of a Task table name, which shouldn't impact existing records or any other functionalities.
That said, 1.2.4 is an old release. Please consider switching over to 1.3 GA release at the earliest. This release includes migration scripts as well, but again, we make sure to not introduce breaking changes in the minor releases (e.g., 1.2 -> 1.3), so switching to 1.3 should be straightforward.
Here's a roundup of all the new features available in the latest 1.3 release.
Related
I am running gitlab-ce in docker containers. I am currently using version 10.5.4. I want to update because of a few bugs with kubernetes in this old version.
Reading the documentation Here the advice is to "first upgrade to the latest available minor version within your major version."
But reading other docs Here says I should update through each minor version. Is that just to avoid downtime?
What is the simplest Upgrade path for me to 11.8, if we're not too worried about downtime?
For anyone else reading it, the quote from the first link is:
We recommend that you first upgrade to the latest available minor version within your major version. By doing this, you can address any deprecation messages that could change behavior in the next major release.
Based on the table below that, the GitLab upgrade path would be 10.5.4 -> 10.8.(latest), fix the deprecations, then 10.8 -> 11.8. The page makes clear that one can (probably) jump between any patch/minor versions without going through the intermediate steps:
It is considered safe to jump between patch versions and minor versions within one major version.
The second source is presumably the Upgrading without Downtime section immediately below the one linked in the question.
Starting with GitLab 9.1.0 it’s possible to upgrade to a newer major, minor, or patch version of GitLab without having to take your GitLab instance offline. However, for this to work there are the following requirements:
You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to 9.3.
It then provides details on background processes required for migrations. These are substantial, so it makes sense that jumping multiple minor versions could be a bit much is not recommended. One minor version at a time for upgrading without downtime. Useful once you are up-to-date, but may be worth skipping with so many minor versions to get through.
What is the simplest way to migrate a Grails app developed in 3.0.4 to 3.0.6?
The grails documentation recommends to create a new app and migrate every component one by one. But there should be a simple way if we are migrating within version 3?
Any help much appreciated
I run a grails create-app to create a fresh install of the new version. I then copy the files from the new version over top of my older v3 version. It's then pretty simple using version control tools to check for changes that need to be merged. The following files will have some changes that need to be merged into my existing project files:
build.gradle
gradle.properties
To be safe I usually also copy over the following, though they are less likely to have changes:
gradle/
gradlew
gradlew.bat
grails-app/conf/application.yml
grails-app/conf/logback.groovy
grails-app/i18n/messages.properties
grails-app/init//Application.groovy
With version control it usually takes less than a few minutes to review and merge back any changes that need to be retained. I find the process fairly simple.
I think you refer to this documentation https://grails.github.io/grails-doc/latest/guide/upgrading.html which is really about grails 2.x to 3.0.x migration.
In the case you're already on 3.0.4 you can just look at the release note of the version to see what is new and if there's any impact. As you will see its a lot of bug fixes and the introduction of the new web profile to create REST specific applications.
I recently get to know grails and start to using it, I know that grails is a great language and it is very helpful for rapid development, but I cant understand why grails dont have a good backward compatibility, I use grails 2.3.8 and grails 2.4 for my projects but many of sample codes in the internet are 2.2 or less, and it isn't time efficient to convert them to 2.3.8 or 2.4 because there are many changes from one version to another. And some times although I do any things right and every thing must work like it works with grails 2.1 or 2.2 but some things still remains.
Am I wrong? I skipped some things that make converting version so hard?
And above all this, what are the guaranties that projects I'm developing right now will be compatible with higher versions of grails that comes in the future?
Joshua Moore is right with his answer, but I do not see it as passimistic as he does.
The grails development team is brave enough to make changes which break with the past. I consider this as a great feature - Grails does not ride dead horses.
For me, most of the changes don't seem to bee too radical. Most of the time, I skip 2-3 version and then upgrade my apps to the current stable version in less than a day. This also helps me to get to know the new features.
If you don't know how to upgrade, the safest way is to use the grails upgrade command. Just increase you version number step by step and do an upgrade and re-run your test (yes, tests help you in your upgrade process :-). If tests fail, take a look at the great changelogs and the "What new in Grails x.y?" sections of the documentation.
Often it is also helpful to compare your old grails version app with a new and empty target version project with a good comparison tool like BeyondCompare. This way you easily spot changed configurations.
Hope that helps
Update: When you are new to "all those webconcepts" you should first decide on the platform you want to work on. If it is the java ecosystem, Grails is the best webframework on the market :-) Otherwise PHP, Rails, DJango etc. could also be a match.
So if you want to learn Grails (and with Grails all those webconcepts), I would suggest to start reading the Guide which will tell you how Grails works. If you need more examples, I can suggest the "The Definitive Guide to Grails 2" published by Apress. It covers basically the same content as the guide, but it does so by walking you through a process of building a sample application.
When it comes to the samples you find on the net... as soon as you get to know the framework better, you will probaply know ho to handle the examples - but there is no silver bullet...
Nothing guaranties that your projects will be compatible with future versions of Grails. In fact, from my own experience, they won't. Often things change, and sometimes radically too, as Grails matures into higher versions.
The same holds true of backwards compatibility as well.
All you need do is take a look at the introduction section of the Grails documentation to see how often things change significantly between versions. A lot of times these changes require significant refactoring of older projects to upgrade them. I still have several large projects running on the 1.3.x branch of Grails because we don't have the resources (time) to go through and upgrade them.
Often this upgrade process involves creating a new empty project then slowly moving the code from the old project into the new project, updating code to reflect newer means of doing the same thing and testing. It's not easy for projects where you have 100+ Domain classes, 1000+ GSPs, 50+ Services and several hundred thousand lines of tests.
One of the nice features of Solr is its ability to import sql data. However its feature is removed in the bundled version in Datastax. Manually adding the missing jar to $SOLR_HOME/lib and configurations files only make it appear in the Solr portal page, but it still does not work. Datastax is hiding Solr log to some unknown place not documented in its official doc, making troubleshooting more difficult. Has anybody been able to make it work?
Sorry for the inconvenience, but the current releases of DataStax Enterprise do not support the Solr Data Import Handler. This is a known problem. We expect to have it fixed in an upcoming release (likely in a 3.2.x release.)
DataStax Enterprise tightly integrates Solr, so there are configuration differences that need to be taken into account when configuring plugins for Solr. Configuring of DIH will be fixed and documented in an upcoming release.
I've just inherited an application written in Grails (version 1.0.3) and would like to upgrade it to the newest release (version 1.3.5).
I can't seem to find a reference that enumerates the differences between the two versions. I know there is the "grails upgrade" command - but is this the best option given the large differences in versions.
I have a similar question that I asked today as well for upgrading the version of Groovy, and the sntactical differences to be aware of (between version 1.3.5 and 1.7.5) - but I thought it may be best to separate the two questions to focus on each.
Many thanks,
~Aki
Things have changed quite a bit since 1.0.3, and unfortunately grails upgrade isn't going to do much for you.
Two significant changes that come to mind are that there was a bug in 1.0.3 and previous where 1-many and many-to-many collections (hasMany/belongsTo) were supposed to be lazy-loaded but weren't. This was fixed in 1.0.4 and several users found that they were relying on the behavior and saw issues. Most people didn't, and just saw a significant performance boost. So watch out for lazy loading exceptions.
Another thing that changed is that plugins are no longer in the root of the project in the 'plugins' folder but are now stored under your $HOME/.grails folder. If you've checked the plugins into source control (and especially if you've made any changes) then you can revert to 1.0.x behavior by adding a property to BuildConfig.groovy (a new file that was introduced in 1.1):
grails.project.plugins.dir = 'plugins'
I described my process for upgrading plugins and apps here: How to install Grails plugin from source code? - it's about a plugin project but the same goes for app upgrades.
The log4j configuration changed from one that's properties-based to a DSL. This means that if you leep your config settings from Config.groovy the log4j behavior will be the default, so you'll need to convert that.
Another change that isn't required but should be considered is that Ivy jar file resolution from Maven repos is now preferred over putting jar files in the lib directory. You can still put them in the lib dir, but it's more DRY to have Ivy download them once.
You'll probably also find that some of the plugins you have don't work in 1.3, so there might be some migration work there.
There are two recent books that cover Grails 1.2/1.3, "Grails: A Quick-Start Guide": http://www.amazon.com/dp/1934356468/ and "Getting Started with Grails, 2nd ed": http://www.infoq.com/minibooks/grails-getting-started - you should probably check those out since they're the most current Grails books.
Overall it shouldn't be that bad, as long as you don't try to upgrade in-place. Use the approach I described in the other post I referenced, i.e. create empty apps and diff files to see what changed (basically a 3-way diff).
The newest release is 1.3.6 (as of Dec 15). You can get a list of changes from the Release Notes of each release. Also, the upgrading from previous versions link the documentation is a good source of changes.