Doctrine ORM Fail (ClassMetadataFactory.php) - doctrine-orm

recently I made an update of my project with silex 2.0 and mark me the following error mapping Parse error: syntax error, unexpected '[', expecting ')' in/var/www/vhosts/server.com.mx/cmanager.server.com.mx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php on line 80.
This makes certain tables not all inclusive had to change database administrator and works perfect.
Have a comment or suggestion.
Thank You

I'm guessing you accidentally upgraded doctrine when upgrading to silex 2.0. If you simply ran composer update instead of composer update silex/silex, you will update all your composer dependencies, including doctrine.
As of doctrine 2.5, it no longer supports php 5.3. You can upgrade your server to PHP 5.4 or later to fix this.
Alternatively, just downgrade doctrine to version 2.4. Put this into your composer.json:
"doctrine/orm": "2.4.*
Edit: It looks like doctrine 2.5 isn't fully released yet. Do you have your minimum-stability flag set to allow unstable versions? If so, I would also recommend fixing that. You should not be using dev builds in a production project.
Edit 2: It's released now.

Related

Upgrade from Sitecore 9.0 to Sitecore 9.2

I am trying to upgrade Sitecore 9.0 to Sitecore 9.2. Couldn't find any specific way except first upgrading to Sitecore 9.0.2 and then proceed further. But, this way getting many errors related with config file. Is there any other way to upgrade directly to 9.2 verion? Any help would be a highly appreciated. Thanks.
The alternative method to 'upgrade' which I often look to is to spin up a clean install of the newer version and then migrate my old code into a new solution which will already have all the latest configs/ Sitecore base code in place.
Doing this means you can just patch your custom app config settings and ensure the Sitecore dependencies in your solution are the newer version which can often be a cleaner/simpler way to go.
There are a couple of things to consider before doing this however, such as whether you need to keep your data in XDB etc. as it would mean that you may need to look at migrating it which can be a pain and since you are looking at 9.0 to 9.2, you'd have additional services to consider as well such as Identity and may need to account for that kind of thing too.

Flyway 3.0 to 4.0 upgrade fails (at least for Postgres)

We tried to go directly from Flyway 3.0 to 4.0 to get access to Repeatable Migrations. (Thus skipping versions 3.1 and 3.2.)
The SQL run via MetaDataTableImpl.upgradeIfNecessary drops the indexes schema_version_vr_idx and schema_version_ir_idx which did not exist in version 3.0's schema, so Postgres is not happy.
A way to support serveral version upgrade could be to use DROP INDEX IF EXISTS schema_version_vr_idx;, but that needs to be adopted to the different databases of course.
For now I solved the problem by creating these two indexes before running Flyway to upgrade the schema.
Is there a better way to do it?
Actually those indexes did exists by default: https://github.com/flyway/flyway/blob/flyway-3.0/flyway-core/src/main/resources/org/flywaydb/core/internal/dbsupport/postgresql/createMetaDataTable.sql
No idea why or how they were removed on your DB instance.

Migrating From ColdFusion 7 to ColdFusion 11

I'm planning a migration on a server from ColdFusion MX7 (Server 2003) to ColdFusion 11(Server 2012). There is a Other Server Where I need to migrate from ColdFusion 8 (Server 2008) to ColdFusion 11. Does my System effect in any way when upgrading like tags, or compatibility issues. Does anyone know which steps I should without effecting. I know about the code analyzer that we had in Cf administrator. I want to know if there is anything effected seriously when migrating.
Thanks in Advance
Kiran Kumar
The Code Analyzer helps in migrating your applications to ColdFusion 11 from earlier versions of ColdFusion. However, it checks the same for only two versions back. The Code Analyzer reviews the CFML pages that you specify and informs you of any potential compatibility issues. It detects unsupported and deprecated CFML features, and outlines the required implementation changes that ensure a smooth migration.
As far as the code compatibility is concerned, everything "should" work. However, it is recommended to check the code compatibility and deprecated tags (if any). You can refer to https://wikidocs.adobe.com/wiki/display/coldfusionen/Deprecated+Features & https://wikidocs.adobe.com/wiki/display/coldfusionen/Deprecated+tags,+attributes,+and+values.
I have briefly covered the entire Migration process here. So, will not iterate the same. Also, you can have a look at another helpful article for Migration Tweaks.
Having said that all, it's strongly recommended to test your website on the Testing/Development environment, before moving it on Production.
Hope this gives a better picture of the migration process.
I did the migration in the past, did not face important issue, as everyone have a different system the best solution would
- Backup
- Test the upgrade and see
if it's a production machine, you can copy your machine to a vm and test the upgrade there. it's may be a lot of work, but you can not know if you don't test
I am currently moving a ColdFusion 9 site to Coldfusion 11 and the way I tested it was to create a separate set of folders on the ms2013 server. I ran them side by side with a duplicate database with a different name for the test site.
I have moved sites up from 5 to 9 with few issues and the only one that really got me in ColdFusion 11 is dbtype in database functions. It has not only been depreciated but will always throw an error if found.
It also depends on how Coldfusion 11 will react to cfcs and other special tags if you use them. I don't so it was a snap.
Examples:
mydatabase
mydatabase1
mypagesfolder
mypagesfolder1
index.cfm
index1.cfm
Going live was a snap. I just renamed the folders, links*, dsn and renamed index1.cfm to index.cfm.
*Links only need to be changed if posting outside of folder and if so just the path.

Migrating Sitecore 6.6 to Sitecore 8

Recently Sitecore 8 has released and it has came up with lot of exciting new features. So our team decided to move from Sitecore 6.6 to Sitecore 8. Before migrating, i would like to know what all things i should be having in handy. Such as, .net Framework, Hardware configuration, environment etc.
Also, i would like to know the procedure to migrate from 6.6 to 8? I, never involved in sitecore migration project before. Please suggest me some good articles or post here your thoughts.
Thanks in advance. :)
See the Sitecore Compatibility Table for the .NET Framework, SQL Server version and Windows version.
Two common approaches.
1) Follow the Sitecore upgrade path.
2) Package the content, and start with a clean install.
Currently I working on a upgrade with an scripted upgrade that follow the Sitecore path. So I can easy repeat the steps and have the latest content in the databases.
I have some of my findings put down here Sitecore update and modules this article contain also a Related links section. Such as the upgrade white paper from Varun
Depending on how 'cluttered' your existing instance is, you may also want to consider installing a fresh copy of Sitecore 8 and then migrate your data/code to avoid all the hops that would be necessary to get to 8.
May be the following blog might help. Take a look at it.
https://varunvns.wordpress.com/2014/11/11/sitecore-version-upgrade-whitepaper/
I would recommend you make a backup of your site to use as a "sandbox" for the upgrade. Copy your databases and the web root for your site to a new location and then set up an IIS site with appropriate permissions pointing to your copy, and change your connection strings in the copy to point to a copy of the databases you backed up.
Perform the update there and ensure everything is working correctly. Work slowly to make sure you are following instructions correctly and note any special actions you had to take to perform the upgrade. Once you have it upgraded, perform the same process on the "real" site.
If you work with a Sitecore partner, I would highly encourage you to discuss the process with them to learn more specifics about the risks and challenges you may encounter during your upgrade.

.NET 4.0 upgrade error on MSI install - XML does not contain expected attribute error

We have an MSI to install windows service on client machine.
Windows service calls the web service of our server to perform operations.
Initially both the MSI and web service were built using .NET 2.0 framework.
Last quarter we upgraded our systems to .NET 4.0. Though our web service is still ASP.NET i.e. asmx (and not WCF). Also I did set framework 4.0 as the prerequisite for MSI to install.
One of our clients reported this issue:
Client was using .NET framework 2.0, and had the older version of MSI installed in his system.
When he tried to installed the .NET framework 4.0 version of the MSI, was prompted to install framework 4.0 (because of the prerequisite). Once the framework installation finished, he tried to install the MSI and got this error. Can someone please guide me to the resolution. I can provide details if needed.
EDIT 1:
On more research, I found it is my AppName.installstate file. Uninstall removes this file, but upgrade does not do it. The file is lying in the install directory. On a closer look I can see "http://schemas.xmlsoap.org/soap/envelope/:Envelope" in the file contents. Any pointer would be greatly appreciated.
EDIT 2:
Custom action Install creates AppName.installstate file and custom action Uninstall deletes the file. In my case, I am doing an MSI upgrade which does not do anything to this file. When I compared the installstate file from 2.0 and 4.0 (both installed manually), I could see a huge difference in the XML syntax, schema and contents, the reason, I am getting serialization error. Now I need to know why AppName.installstate is not getting overwritten when upgraded. Doing lot of google, but landing nowhere.
Looked at MSI install log, but no useful information.
Eureka !!!!
I found solution to my problem.
Root cause of the problem:
MSI generates an XML file during installation (application_name.installstate), which stores information MSI uses during install, uninstall, rollback. The format of this XML file is completely different between .NET 2.0 and .NET 4.0 i.e. MSI developed using VS2005 and VS2010.
Because 4.0 frmaework is not able to understand the file generated by Old Framework version (2.0), we are getting the error saying “Not able to serialize the Type of the Installstate file”.
Though there is no documentation available online for this, there is this discussion I found > http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/bedbb8bd-dad5-4bcb-a87a-ac69386669b4/
Solution I tried (I would call it work-around):
During installation of the New version, I am explicitly replacing the old XML file with the new format (4.0). i.e I included application_Name.installstate file (generated by new version) in my package, so it overwrote the old file while upgrade.
MSI got installed without any error and is running successfully.
Reply here if anybody needs detail on both problem and solution.
This error message has nothing to do with the installer per the 1001 error message. The problem is fully inside your service.
Your service's OnStart method should be doing nothing but spinning up a background process and returning success start to the service control manager as quickly as possible. There shouldn't be any long running code in that critical path as the SCM will only wait so long before assuming there was an error starting the service.
Refactor your service to run the job on another thread and the install will successfully install. From there you can focus on the real problem of what's going on in your DeSerialization process.