I use Flyway's migrate when I start my application to, well, migrate the database. As per default validateOnMigrate is enabled and validate reports an error if a already applied file is changed.
So far so good, but it seems to ignore cases where an already applied file is missing.
Secondly, if the schema contains a migration that is newer than the latest available, migrate logs a warning but doesn't fail either, for example:
Schema xxx has a version (1.1.1) that is newer than the latest
available migration (1.0.1) !
Is there a way to prevent this behaviour? I would like to have options like failIfMigrationIsMissing and failIfSchemaIsNewer.
All of this would be useful to make sure nobody installs or starts an older version on top of a newer database, e.g. downgrades. Actually I thought this would be the default behaviour, or do I miss something here?
Here's a scheme that works with flyway 4.0.3. You can check all the migrations if your versioning is more complex.
flyway.migrate();
MigrationInfoService migrationInfoService = flyway.info();
MigrationInfo[] applied = migrationInfoService.applied();
MigrationInfo last = applied[applied.length - 1];
if (MigrationState.FUTURE_SUCCESS.equals(last.getState())) {
throw new Exception("Database downgrade detected.");
}
Related
I have an old Symfony website which is using the framework bundle but no database is required for the content. This works fine till 4.4.18 but upgrading to the latest version is giving the following error:
An exception occurred in driver: could not find driver
I haven't modified DATABASE_URL in .env or configured the driver in config/packages/doctrine.yaml. Is there anyway I can simple disable the use of database?
Thanks to the comment from #cerad, removing doctrine-migrations package from composer.json helped with the issue.
As I am not using a Database for the site, this is fine for me.
if your app doesn't use the database the best course of action is to remove the doctrine/doctrine-bundle and/or symfony/orm-pack (if you've installed the orm support via pack)
if that's not an option than set the DATABASE_URL= to nothing (like that, not the empty string), or if you've hit some bug in dbal dsn parsing give it the dummy sqlite until the issue gets resolved DATABASE_URL="sqlite:///%kernel.project_dir%/var/data.db"
I need to upgrade an existing rather large application from Symfony 2.0.15 to Symfony 2.4.x (replace with current version).
I'm not quite sure what would be the best strategy to do so. Migration critical features like forms or esi are used, of course :)
Upgrade "step by step" from one major version to another (2.1, 2.2, 2.3, 2.4)
Upgrade directly from 2.0.x to 2.4
Do you have any tips / experience to share ? Would appreciate it :)
Thanks,
Stephan
Each new version comes with an update UPGRADE-2.x.md file containing all intructions to convert your application from the immediately previous version.
I had to do that on my project as well, and I found the step-by-step method more natural and easier to manage. Fact is, there is no file such file as UPGRADE-2.0-to-2.4.md that would help you out for a direct conversion to 2.4.
I shall first recommend to make sure that none of your code uses obsolete functionnalities of Symfony 2.0 (not sure if there are deprecated parts in this version, though), because these can be removed in ulterior versions and will not be included in the UPGRADE file.
If you have done indeep modifications of the core Symfony code, you may find that some undocumented modifications are needed. For instance, there is a custom error handler in my project, extending the Symfony error handler. Well, although it was not documented in the UPGRADE file, the signature of ErrorHandler::handle() was modified and needed to be updated in my custom handler.
Similarly, I had to modify some namespaces because files had been moved in the framework code.
The conversion is still ongoing and I'm currently experiencing a weird error I'm trying to get rid of: The 'request' scope on services registered on custom events generates errors in the logs.
This code returns null:
session.Binding.GetRepositoryService()
.GetRepositoryInfo(session.RepositoryInfo.Id, null).LatestChangeLogToken
on an Alfresco Community 4.2.e server, just after I turned on ChangeLog and restarted. Before enabling ChangeLog, I had been using this server and adding files, if that matters.
Is this normal? Is it because I have not touched any file since enabling ChangeLog?
Are there any other situations where a null output is normal?
After I add a document, the result is not null anymore.
This is a bug in Alfresco.
The workaround is to perform a change (for instance create and remove a folder) before using the repository.
The bug has been fixed in Alfresco 5.0.2.
Details: https://issues.alfresco.com/jira/browse/MNT-13529
I am wondering if there is any news for multi line comment directive support for MySql.
I believe the problem is related to:
Mysql dump comments directives and simple comments
Basically it seems SqlScript/MySQLSqlStatementBuilder fail in recognizing as directive a statement in the format:
/*!50001 <STATEMENT SPLITTED IN
MULTI
LINES> */;
I am using version 2.2.1
Additional notes:
the same goes for previous versions (2.1.1), and issues are multiple and not only related to comment directives; theu are also hard to debug because of missing exception trace.
Basically I think parser cannot currently handle pretty standard mysql scripts created with mysqldump; this IMO is a necessary feature for any usage in existing projects at least.
If anybody has suggestions to overcome these issues, it would be highly appreciated.
I am using Flyway 2.1.1 API in Java.
What I am doing is parsing a dump file (only the schema structure) and replace the version dependant comments.
This solution is pretty bad, but waiting for a better support of MySQL dump in Flyway, I didn't find anything else...
I am developing DotNetNuke modules and naturally want them compiled before installing or distributing them. In the past I've simply referenced a specific version of DotNetNuke.dll by browsing to the /BIN folder of a local DotNetNuke installation.
This reference allowed me to use the DNN base classes and create my own set of classes upon those. I also use various helper methods throughout the DNN namespaces/classes that I require. (i.e. Make derived classes from their PortalModuleBase, ModuleSettingsBase and use their Localization classes which replace those provided by Microsoft's ASP.NET implementation.)
I've been able to get away with this approach making that direct DLL reference (Copy Local = True, Specific Version = False) because until now I've been installing these modules onto client websites that I maintain. As such, I've kept them on at least the version of DotNetNuke I've been developing on - or newer. Most recently, I was referencing 6.1.3.108 in development.
NOTE: This automatically copies in the following associated DLLs into the /BIN directory of my modules:
DotNetNuke.dll
DotNetNuke.Instrumentation.dll
dotnetnuke.log4net.dll
DotNetNuke.Services.Syndication.dll
DotNetNuke.Web.Client.dll
DotNetNuke.WebControls.dll
DotNetNuke.WebUtility.dll
Installing this onto a DotNetNuke site of a NEWER version worked fine, which isn't a bad start.
What I've been wondering though, is if there is a non-hackish way of making my modules insensitive to the minor, build or revision levels of the DLL?
I realize that it makes it my responsibility to ensure the product (if developed on a "mid range" version) still works on slightly earlier as well as newer versions of the product. That said, I feel I can do thorough testing across those builds. To me this is preferential to having to run the OLDEST major build in development.
Put another way, I'd rather not develop with references to 6.0.0.0 just so it works on 6.x.x.x without extra effort. I'll only do that if someone doesn't have a brilliant way for me to make referencing say, 6.1.3.108 working on slightly earlier or later versions. (Naturally I'm okay with having to make a different module for major version changes, such as 5.x.x.x or 7.x.x.x.)
Thanks in advance!
Instead of referencing the assemblies in the bin folder, keep a copy of DotNetNuke.dll (and any other references) with your source code, and reference it there. Put the oldest supported version there, but develop on a newer site. Set Copy Local=False on the reference so you don't overwrite the newer version, and you should be fine.
In this way, we're able to reference DNN 4.5.3 while developing a module that runs on DNN 6.1.x. I've been using this method for years without any significant problems (except when I occasionally forget to turn off Copy Local and my DNN site mysteriously blows up).
In regards to determining the version of DNN in a class you've subclassed from a DNN one.
Here's what I would do, assuming YourClass inherits from DNNClass, but because you have referenced an earlier version of a property, 'NewProp' doesn't exist. Here's how to do it:
public class YourClass : DNNClass
{
public string NewPropSubstitute
{
get {
string newPropVal = "your default if earlier DNN";
System.Reflection.PropertyInfo pi = this.GetType().GetProperty("NewProp");
if (pi != null)
newPropVal = (string)pi.GetValue(this, null);
return newPropVal;
}
}
}
That's a made-from-memory guess so it might not compile, but you get the idea. You don't necessarily have to get the DNN Version if you want - just try and get the property through reflection - if it's there, implicitly you've got the right version.
Of course this method assumes you can substitute in a value for a later-DNN property (or method) if the DNN version doesn't support it. But that all depends on what you're trying to do.
If you do want to find the DNN Version (version safe and always correct) you can use the code for that which is embedded in my version-safe jQuery inclusion code, linked from this blog post:
Using jQuery in DotNetNuke 5 and 6