I am trying to upgrade my app from GAE 1.8.1 to 1.9.3, apparently there is one major issue with retrieving child records in any one to many relationship I have.
In the old version I was using datanucleus JDO version 1 and everything worked fine. Now I am using version 2.
After the upgrade I can only retrieve parent objects (the child are nulls), although when I create new data it seems to be working fine.
I checked how the new data looks like in the database viewer, and it seems that the one-to-many column in the class of the old data is labeled as "missing".
If I create new data the data is filled with some index information.
I will appreciate any help
Update
Apparently datanucleus JDO version 2 is not fully backward compatible to version 1. If you're going to consider an upgrade verified the data relationships were not broken (like mine did)
My current solution is to stay with version 1 and use the newest GAE SDK (which seems to be working well)
Apparently datanucleus JDO version 2 is not fully backward compatible to version 1. If you're going to consider an upgrade verified the data relationships were not broken (like mine did)
My current solution is to stay with version 1 and use the newest GAE SDK (which seems to be working well)
Related
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.
I am working on Adobe CQ. I created 2-3 versions(1.2,1.2,1.3) for a particular page in my author instance. Now I tried to package my content page and installed it in another instance. I couldn't see the versions of the page which I installed in another instance.
Can anyone help me out doing this?? I want to migrate my content pages along with their versions from one CQ instance to another??
We are in the same situation. You can extract prior version details using the packaging approach, but you will be precluded from reloading them in due to the new Oak security model. The next issue is that you would need to extract and transform the data, and then reinsert due to the node ID's potentially differing, especially if you are using partial data sets to extract.
Where we have gotten to, and are proving now, is to use the new migration tool to move content from instance to instance, which purportedly has a version extract tool. I will update details here when we get our results back.
UPDATE:
We have tested the CRX2OAK migration tool, and it indeed does move versions across. Using the tool, you can specify filters to only migrate a subset of content, which will then drag the version details across as well.
It seems this approach works quite well for both single tenancy and multi tenancy approaches as it used to using a package for content.
Unfortunately, it can't be used as a portable backup system, as it is an instance to instance solution. It does, however, work well for blue/green deployment strategies.
Versions are stored by path '/jcr:system/jcr:versionStorage' in AEM.
To transfer pages with their versions just create a package with filters for content which you want to move and the version storage path as well, download package and install in other AEM.
If anyone comes across this question like me, here is the summarised answer:
You can use crx2oak utility available from link below to migrate pages and page version across instances:
https://repo.adobe.com/nexus/content/groups/public/com/adobe/granite/crx2oak/
This is a powerful utility with multiple uses (especially in upgrades) as documented in links below:
https://docs.adobe.com/docs/en/aem/6-2/deploy/upgrade/using-crx2oak.html
https://jackrabbit.apache.org/oak/docs/migration.html
The source and destination repositories need to be offline while running this utility so best to plan ahead for this type of migration.
HTH
I'm nearling completion of my first CakePHP-driven website and just saw they're already working on CakePHP 2.0 (not the stable release yet).
My questions:
Is it incredibly time consuming to move to a new version of CakePHP (when it becomes the "stable" release that is)? I know they have migration guides, but - I've never used a framework before, so I've never had to migrate anything.
Do you migrate your code for existing projects, or leave it as is and use the new stable version for future projects only?
Where can I find what version of CakePHP I currently have installed? I've looked at the LICENCE and VERSION files, but cannot find the installed/current version listed in them.
These seem like simple questions, but I greatly appreciate any thoughts/advice - searching this on Google just brings up how-to-migrate pages, not pros/cons...etc.
I've migrated a few sites from CakePHP 1.2 to 1.3. In my experience, it takes 2-3 hours on sites that have 5-10 controllers and no custom plugins, etc. I find I typically only have to change the syntax on a handful of function calls, and when I figure out which ones, it is just a matter of doing a find / replace across the site. Of course it could be more of an issue going from 1.3 to 2.0, but I don't get the sense that it will be an especially drastic API change.
UPDATE: I'm now in the process of migrating to CakePHP 2.0 beta, and thought I should update this, as I'm finding the updates are more extensive and far-reaching than I had assumed when I wrote this. Migration guide here: https://github.com/cakephp/docs/blob/master/en/appendices/2-0-migration-guide.rst
ANOTHER UPDATE: Since people seem to be finding this useful, I just thought I'd point out that Cake now helpfully provides an upgrade shell that does some of the work for you. Note that although the documentation says it will do "most" of the work, I have found there are still quite a few function calls, etc. that will need to be updated manually (see migration guide).
http://book2.cakephp.org/en/console-and-shells/upgrade-shell.html
As dhofstet said, it will all depend on the size and complexity of your site.
Whether you upgrade at all is usually a judgment call, but sometimes you have to (e.g. Cake 1.2 has some code that will break if your host upgrades to PHP 5.3). You certainly wouldn't have the kind of security issues that an old WordPress, Drupal, etc install would have. I have seen some noticeable speed increases with Cake upgrades, so depending on the situation it could be worth the trouble just for that (Cake 2.0 finally drops PHP 4 suppport). Look at the release notes and see if there are things that appeal to you in the new version.
To see your version, in the cake/VERSION.txt file, look at the very last line. It's easy to miss, but it should just be a number, e.g. 1.3.8.
This question is difficult to answer as it depends on the size and complexity of your project(s). The "big" releases (from 1.1 -> 1.2, 1.2 -> 1.3, 1.3 -> 2.0) usually break stuff and so you have to budget some migration work. The migration between "smaller" releases (for example from 1.3.9 to 1.3.10), on the other hand, is usually easy, often it just means to replace the cake folder. In both cases it is useful to have tests.
I migrate the projects which are actively maintained.
You can find the CakePHP version in cake/config/config.php
I'm migrating an app 1.3»2.0rc1 right now and I got no big trouble.
I had to change names of folder/files, eg. app_controller.php » Controller/AppController.php
Follow the migration link (tmp link) http://book2.cakephp.org/en/appendices/2-0-migration-guide.html
plugins/components/.. from various source won't work (at minus, for point 1)
To update the code (which in my case wasn't needed as the app worked well) I've shell-baked a dummy table and looked at differences in code.. It's a good starting point
Authentication/Authorization changed in some config, but requires few changes.
Trees still working
Acl don't. But I'm quite sure it's my fault.
For now it's all, good work!
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.