We would be doing a POC on having a DevOps with Snowflake. I wanted to know which tools can be used referred to and any doc/implementation references would be helpful.
Version controlling should be there.
Code rollback scenarios(like all versions of DB object should be tracked)
To elaborate, if a table is deployed to Snowflake as part of 5 changes
which is expected to have 5 versions (V1, V2, V3, V4, V5), then in this case if we want
to see the version V2(code) of the table then we should see that.
CI~CD pipeline implementation.
Thanks in advance for all your inputs.
Regards,
Somen Swain
Related
how can i perfom full data migration from ElasticSearch 5.6.16 to 7.2.0. I have an application running version 5.6.16. No i have to update some of the data to version 7.2.0. The manufacturer has written / provided an own tool for the migration, but this requires that the new installation (7.2.0) has been installed on a new separate server. But this is the only the last option for me. So what's an easy and good way to do this on the same machine? Or would it be an solution to install the new version (7.2.0) on the same machine with different port and then do my stuff as this would be two servers?
First backup the data and the re-import after installing new version? Did i get problems with the indexes (i read something about this.. that this could result in errors)
You have few questions but I will try to answer two important ones,
How can you run the two different version of elasticsearch on a single machine
Answer : it is possible although not recommended in production environment, as you guess it right, by running these two version on different ports.
How to migrate from ES 5.6 to 7.2
Answer: Elasticsearch provides the backward compatibility till last major version, so if you are upgrading to 7.X, than ES 6.X indices can be backed up and re-imported in ES 7.X but you can't do this for 5.X indices.
Note: Refer upgrade elasticsearch official doc for detailed explanation and process.
I am checking out the documentation on IBM Cognitive Services and have come across two ways of connecting to my existing workspace.
Version 1
Version 2
My question is which of them is the one that needs to be used. They both appear to work but I am not sure which one to go with. Is there another API that is latest perhaps?
The latest version API will be on the release notes and the API reference.
https://www.ibm.com/watson/developercloud/doc/conversation/release-notes.html
Using an earlier version number will disable later features, but any workspace created with a later version may not be backward compatible, and results may be unpredictable.
There is currently no way to create earlier workspace structures once there has been an update to the version. But if you have older workspaces, they will still remain compatible.
solr
Now i am using solr4. I need to migrate solr to latest version.
Which solr version is latest and stable?
What are the conditions i need to check for migration?
How can i merge this version to latest version?
Which version can u prefer for me?
any migration tool is available for this migration?
I think about solr 6.3.0
Is it stable ?
What are the manger difference in solr 4 and 6 ??
When upgrading you really have to choices:
Reindex. This is the easiest (and you should have a way to reindex on request anyway, but some use cases makes reindexing hard, since Solr could be your primary datastore), most flexible and gives you the best end result.
Do a version-by-version upgrade, going from each version that supports the old index format to the most recent version that supports that format, then repeat until you're on your target version of Solr. Since old index versions are usually readable through each main version tree (I think), you'll have to go 4 -> 5 -> 6. You can use the IndexUpgrader tool to help with this, and as you can see at the bottom of that page, Jan made a tool that automates 4 -> 5 -> 6 for you.
The differences are far too many to really list, please refer to the Changelog for each release. In particular there's a world of difference regarding cloud / cluster support between 4.x and 6.x, and there's a lot of new features, such as streaming expressions.
Upgrading the schema is a matter of going through the datatypes you're using and checking if they've changed definitions (ints vs tries, for example). You'll probably be OK with just minor changes. The default schema factory has changed from the classic index schema to the managed schema, so if you want to keep editing the schema.xml as you're used to, you'll have to change to the ClassicIndexSchemaFactory in your configuration.
There are at least two Grails plugins that emulate the database migration functionality of Rails:
Autobase
Liquibase
Is there a consensus about which of these is best, or is there another plugin that does database migration better than either of the above?
There is now a standard Grails database migration plugin available. According to this blog post at least the liquibase plugin will therefore not be maintained past the liquibase 1.9 release anymore.
The new database migration plugin has built-in functionality to execute changelogs on startup and supports the definition of changes in Groovy DSL, so it's probably what you are looking for.
I use Autobase (which is built on top of Liquibase) as it (last time I checked) allows you to automatically check/apply your migrations when the app starts. With the Liquibase plugin I have to do this myself in servlet init code. This allows you to set your datasource to dbCreate = none and let Autobase handle getting the DB into shape.
It does mean you need to write a migration each time you add a property to a domain class, but I think this is a good thing as it makes you think about what the underlying field should actually be instead of just letting Hibernate take a guess at it.
I think some of the Autobase plugin (e.g. the groovy dsl) is being migrated back to the Liquibase plugin, but you'd need to check up on that.
The only downside to Autobase is the lack of good documentation. There is some but it's not complete. Luckily, the dsl is the same as the xml Liquibase tags so you can work most of it out.
I use liquibase, I'm not sure that Robert is still actively maintaining Autobase and the xml that liquibase provides is actually pretty DSL-like. I think it also gives a little bit of separation to your database commands and doesn't make it ingrained into the start-up process (some people might prefer the reverse).
At least as of Grails2.0, the database migration plugin is the defacto way to handle non-trivial database changes. The plugin is built on Liquibase, and is authored by the Springsource folks - always a mark of quality. I wrote an introduction to the database migration plugin which might be of use to someone reading this.
I have heard that Autobase is still maintained, but consider that the Grails Database Migration Plugin is written by the core team, and likely going to be the officially supported one.
In other words, encourage you can wait on Grails 1.4 --> roadmap before choosing either of the plugins above.
YEs i also see the migration pluging. This is helpful...
http://grails-plugins.github.io/grails-database-migration/
Since I've not done this before I am not sure if the way I am planning to do this is okay or is there a better way. Like using Windows Installer or Install Shield or Windows Installer XML (WiX) toolset. Any help would be great, as I have no clue.
We have a product and we ship new version every few months. So far we've only been rolling out complete versions i.e. Either Version 1.0, or Version 1.5, but no upgrade from 1.0 to 1.2 to 1.3 to .... you get the picture, right! So any customer that get version 1.0 cannot upgrade to version 1.2 or 1.3 or even the latest. They'll have to uninstall old version and install the latest version. This is not right, but thats what we could do until now. But we'd like to change it.
My plan is to have a install file with (Sql Scripts) for each upgrade path. Check the table in database that stores the version info and depending on it run different script to upgrade database.
My concern is that this method may not be scalable, once we have more than 5 or 6 different versions.
If you could point to any articles or books on this topic, that would help a lot too.
Also, could we use Windows Installer or Install Shield for this?
thanks,
_UB
We've been using DBGhost for a year or so now to keep our database under source control along with our codebase, and it makes this kind of thing dead easy. It's not just well thought through, but they've been using it to roll out their own code for years, so it's dead solid.
Your problem is a pretty common one, and I've had to deal with this kind of problem at my last job. There is another tool aside from the RedGate tool that may help you do what you need to do. It's a tool called DB Ghost. They explicitly address the versioning problem, and have a packager as well. I would suggest doing a trial of the DB Ghost product because they have some interesting claims concerning multiple version upgrades. This was taken from their FAQ (http://www.innovartis.co.uk/faqs/faqs.aspx):
Q: Our problem is going to be managing
data structure changes during
upgrades. Our product line is
Shrink-Wrapped, or downloadable from
the website. So when a user downloads
an upgrade, they can be upgrading from
a very recent version, with few
database structure changes, or the
upgrade may be from a very old version
with a multitude of structural
changes. One upgrade needs to manage
it all. The user would be offsite, so
we can't hold their hand. We have
users in Greece, Australia, Malaysia,
Norway, etc. How would DB Ghost, if at
all, handle updates in remote
locations?
A: The DB Ghost Packager Plus product was
design to specifically address this
issue as it can dynamically handle the
required updates to a target database
seamlessly.
I'm just mentioning this because our company is trying to do something similar and I was doing research on this tool.
Thanks,
Eric
Do you insist on doing it yourself, or could you see yourself committing and investing in a tool?
I really like the idea of Red-Gate's SQL Packager, which will "diff" your two database versions, and then create a SQL script, a C# project, or a stand-alone executable to upgrade from version 1 to version 2.
Not 100% how you'd be able to upgrade from 1.0, 1.1, 1.2, 1.3 all to 2.0 - check out their website and see if they offer something for that scenario!
Otherwise, I guess it'll get quite thorny and messy......
Marc
In the Rails world they are using a tool/method called Migrations.
Basically is boils down to creating a small sql script to upgrade and downgrade each little change to the database.
When you are testing the application you migrate your database to the version you want and on deployment the application can check what version it needs and migrate to that version.
There are free migration toolkits for most popular languages, they might be part of some MVC framework though.
A nice side effect of migrations is that you have database source code that is easily stored in you source control repository.