I'm observing some strange Flyway behaviour when using repeatable migrations. Documentation states, that:
Within a single migration run, repeatable migrations are always applied last, after all pending versioned migrations have been executed.
but in my case it seems, that the repeatable migration (which is recreating one of the DB views) is failing because it is being executed before versioned migrations.
Flyway info data, from before migration:
+-------------------+---------------------+---------------------+---------+
| Version | Description | Installed on | State |
+-------------------+---------------------+---------------------+---------+
| 1 | Initial | | <Baseln |
| 2 | ███████████████████ | | <Baseln |
| 5 | Initial data | | <Baseln |
| 6 | Initial sample data | 2016-04-29 14:21:13 | Success |
| 20160422002600000 | ███████████████████ | 2016-04-29 14:33:48 | Success |
| 20160422003400000 | ███████████████████ | 2016-04-29 14:33:48 | Success |
| 20160422004700000 | ███████████████████ | 2016-04-29 14:33:48 | Success |
| 20160428152800000 | ███████████████████ | 2016-04-29 14:33:48 | Success |
| 20160428163300000 | ███████████████████ | 2016-04-29 14:33:48 | Success |
| 20160428171300000 | ███████████████████ | 2016-04-29 14:33:48 | Success |
| | ProblematicView | 2016-04-29 14:33:48 | Outdate |
| | Reports | 2016-04-29 14:33:49 | Success |
| | OtherView | 2016-04-29 14:33:49 | Success |
| 20160429115100000 | ███████████████████ | 2016-04-29 14:37:10 | Success |
| 20160429160100000 | ███████████████████ | 2016-05-16 11:54:24 | Success |
| 20160501090500000 | ███████████████████ | 2016-05-16 11:54:24 | Success |
| 20160504111600000 | ███████████████████ | 2016-05-16 11:54:24 | Success |
| 20160504120400000 | ███████████████████ | 2016-05-16 11:54:24 | Success |
| 20160504143800000 | ███████████████████ | 2016-05-16 11:54:24 | Success |
| 20160504145200000 | ███████████████████ | 2016-05-16 11:54:25 | Success |
| 20160504161600000 | ███████████████████ | | Pending |
| 20160506110300000 | ███████████████████ | | Pending |
| 20160506162300000 | ███████████████████ | | Pending |
| 20160506232000000 | ███████████████████ | | Pending |
| 20160508144100000 | ███████████████████ | | Pending |
| 20160509192400000 | ███████████████████ | | Pending |
| 20160511160000000 | ███████████████████ | | Pending |
| 20160511163659000 | ███████████████████ | | Pending |
| 20160511163700000 | A newly_created_col | | Pending |
| 20160511170000000 | ███████████████████ | | Pending |
| 20160512112100000 | ███████████████████ | | Pending |
| 20160512170500000 | ███████████████████ | | Pending |
| 20160513134900000 | ███████████████████ | | Pending |
+-------------------+---------------------+-------------------------------+
and the migration log:
[INFO] Database: jdbc:sqlserver://█:1433;authenticationScheme=nativeAuthentication;xopenStates=false;sendTimeAsDatetime=true;trustServerCertificate=false;sendStringParametersAsUnicode=true;selectMethod=direct;responseBuffering=adaptive;packetSize=8000;multiSubnetFailover=false;loginTimeout=15;lockTimeout=-1;lastUpdateCount=true;encrypt=false;disableStatementPooling=true;databaseName=█;applicationName=Microsoft JDBC Driver for SQL Server;applicationIntent=readwrite; (Microsoft SQL Server 11.0)
[INFO] Successfully validated 33 migrations (execution time 00:00.052s)
[INFO] SQLServer does not support setting the schema for the current session. Default schema NOT changed to dbo
[INFO] Current version of schema [dbo]: 20160504145200000
[WARNING] outOfOrder mode is active. Migration of schema [dbo] may not be reproducible.
[INFO] Migrating schema [dbo] with repeatable migration ProblematicView
[ERROR] Migration of schema [dbo] with repeatable migration ProblematicView failed! Changes successfully rolled back.
[INFO] SQLServer does not support setting the schema for the current session. Default schema NOT changed to dbo
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.550s
[INFO] Finished at: Mon May 16 12:40:49 CEST 2016
[INFO] Final Memory: 10M/243M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.flywaydb:flyway-maven-plugin:4.0.1:migrate (migrate-¦) on project ¦-db: org.flywaydb.core.internal.dbsupport.FlywaySqlScriptException:
[ERROR] Migration R__ProblematicView.sql failed
[ERROR] ------------------------------------------------
[ERROR] SQL State : S0001
[ERROR] Error Code : 207
[ERROR] Message : Invalid column name 'newly_created_column'. /*<-- column created in V20160511163700000*/`
Am I doing something wrong?
I'm using flyway-maven-plugin 4.0.1 (tested also on 4.0) with the following properties:
Maven:
<cleanDisabled>true</cleanDisabled>
<outOfOrder>true</outOfOrder>
<table>schema_version</table>
<repeatableSqlMigrationPrefix>R</repeatableSqlMigrationPrefix>
<sqlMigrationPrefix>V</sqlMigrationPrefix>
Config file:
flyway.user=flyway
flyway.password=█
flyway.url=jdbc:sqlserver://█;databasename=█
flyway.locations=filesystem:flyway/upgrade/█`
//EDIT1:
When outOfOrder is set to false the migration is still failing,
clean + migrate seem to work, but that doesn't quite solve the problem,
I've noticed one more thing - when I've rolled back the DB to version 20160504143800000 repeatable migrations are shown at the end of the list (flyway info), but when 20160504145200000 migration is successfully executed suddenly they're in the middle of it (as in the table above). I'm not sure though if this has anything to do with the actual execution order.
It turned out to be a bug in Flyway: LINK - it affects releases 4.0 - 4.0.2 and has been fixed in 4.0.3 (Release notes).
I can confirm that now it works as expected both on empty and existing databases.
It would be worth you changing the outOfOrder property to false so that migrations can only happen in their defined order.
If you are still seeing a problem, can you also set cleanDisabled to false so that the schema is totally rebuilt and report what you see.
Both of the above cause flyway to work in a more certain way and so allow other people to be more certain about the order of events are commenting on.
Related
In Katalon Chrome addon or Selenium Chrome addon, I'm trying to set up a simple check to verify if an element contains a specific text.
Here is what I've done so far :
Katalon Recorder (Example):
Command | Target | Value
click | id=subscribed |
StoreText | id=subscribed | i
echo | ${i}
verifyText | id=subscribed | alyx
Log result :
[info] Executing: | click | id=subscribed | |
[info] Executing: | storeText | id=subscribed | i |
[info] Store 'alyx.vance' into 'i'
[info] Executing: | echo | ${i} | |
[info] Expand variable '${i}' into 'alyx.vance'
[info] echo: alyx.vance
[info] Executing: | verifyText | id=subscribed | alyx |
From here, how can I set up this? :
If VerifyText = alyx (Contains) => Goto Label X (True)
If VerifyText != alyx (Not Contains) => Goto Label Y (False)
Thank you for your help.
I've finaly found the solution and it works that way on my script :
Command | Target | Value
click | id=subscribed
StoreText | id=subscribed | i
echo | ${i}
storeText | alyx.vance | j
if | ('${i}').includes('${j}')
gotoLabel | X
else
gotoLabel | Y
...
endif
It works for me but in certain cases, it might not work so, if you need help :)
How about:
storeText | id=subscribed | i
store | alyx.vance | j
if | ${i} == ${j}
click | Label_X_locator
elseIf | ${i} != ${j}
click | Label_Y_locator
endIf
Is there a way in Flask-SocketIO to have a blocking/synchronous emit('event', callback) function that waits for the callback passed to it before returning?
Or -- is there a way to directly invoke the callback in an #socketio.on('event') handler instead of the plain return from that handler?
This is my situation specifically:
+-----------------+ +----------------------+ +----------------------+
| Browser | emit('serverGiveData', | Flask | emit('workerGiveData', | Worker |
| (webapp, JS) | browser_callback) | web server | server_callback) | (Python program) |
| | +------------------------> | | +--------------------> | |
| | | | | |
| socket.io 1.7.3 | data | Flask-SocketIO 2.8.2 | data |socketiIO-client 0.7.2|
| | <------------------------+ | | <--------------------+ | |
| | | | | |
+-----------------+ +----------------------+ +----------------------+
So the Browser wants data from the Worker and the Flask web server is just a proxy in between.
I would like the browser_callback() to be invoked after the Server receives the data from the Worker.
(I.e. I would like to call the browser_callback() from the server_callback()).
However, I cannot invoke the browser_callback() from server_callback() manually in Flask-SocketIO -- it is "automatically" invoked when I return from 'serverGiveData' handler function on the Server. That is why I would like to have a blocking/synchronous emit('workerGiveData') so that the handler on the Server doesn't return before the Worker delivers the data.
Here's the code
Browser
socketio.emit('serverGiveData', args, function (data) {
console.log('Received data');
});
Server
#socketio.on('serverGiveData')
def handler(msg):
socketio.emit('workerGiveData', msg, callback=server_callback)
return # When server_callback() gets called back
def server_callback(data):
print('Received data from Worker')
# Here I want to invoke client_callback(), i.e.
# I don't want handler() to return before this server_callback() is invoked
Worker
def handler(args, callback);
callback(data)
socketIO.on('workerGiveData', handler)
(I am aware I could emit('heyBrowserHeresData') from the server_callback() when the Worker delivers the data and listen on that event in the browser with browser_callback() code as the handler.
I would like to avoid that jumble.)
The Socket.IO protocol is event-based, not request/response based. I recommend that you don't use the callbacks, those are for quick acknowledgement that an event was received, not to provide results after some work was done.
Try this instead to use a new event to replace your callback:
+-----------------+ +----------------------+ +----------------------+
| Browser | emit('serverGiveData’) | Flask | emit('workerGiveData', | Worker |
| (webapp, JS) | | web server | server_callback) | (Python program) |
| | +------------------------> | | +--------------------> | |
| | | | | |
| socket.io 1.7.3 | emit(‘dataForBrowser’) | Flask-SocketIO 2.8.2 | data |socketiIO-client 0.7.2|
| | <------------------------+ | | <--------------------+ | |
| | | | | |
+-----------------+ +----------------------+ +----------------------+
You can leave the second callback on the server-side if that works well for you, or less you can also replace it with an event.
Finally managed to successfully deploy cloud foundry to AWS.
Mostly following instructions from http://docs.cloudfoundry.org/deploying/ec2/bootstrap-aws-vpc.html
Its failing at the validation step that is to get a success response for the following:
curl api.subdomain.domain/info
Of course I have substituted the subdomain and domain appropriately.
I am getting the error:
404 Not Found: Requested route ('api.XX.XXXXX.com') does not exist.
The request is coming till the Cloud foundry router router_z1. And I can see this error in the logs for router_z1.
Here is output of my bosh vms command:
------------------------------------+---------+---------------+--------------+
| Job/index | State | Resource Pool | IPs |
+------------------------------------+---------+---------------+--------------+
| unknown/unknown | running | medium_z1 | 10.10.16.254 |
| unknown/unknown | running | medium_z2 | 10.10.81.4 |
| unknown/unknown | running | small_errand | 10.10.17.1 |
| unknown/unknown | running | small_errand | 10.10.17.0 |
| api_worker_z1/0 | running | small_z1 | 10.10.17.20 |
| api_z1/0 | running | large_z1 | 10.10.17.18 |
| clock_global/0 | running | medium_z1 | 10.10.17.19 |
| etcd_z1/0 | running | medium_z1 | 10.10.16.20 |
| hm9000_z1/0 | running | medium_z1 | 10.10.17.21 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 | 10.10.16.34 |
| loggregator_z1/0 | running | medium_z1 | 10.10.16.31 |
| login_z1/0 | running | medium_z1 | 10.10.17.17 |
| nats_z1/0 | running | medium_z1 | 10.10.16.11 |
| router_z1/0 | running | router_z1 | 10.10.16.15 |
| runner_z1/0 | running | runner_z1 | 10.10.17.22 |
| stats_z1/0 | running | small_z1 | 10.10.17.15 |
| uaa_z1/0 | running | medium_z1 | 10.10.17.16 |
+------------------------------------+---------+---------------+--------------+
The only change that I made in the CF deployment manifest was to eliminate instance from zone 2. The reason being AWS default limit for number of instances on EC2 in a particular region is 20.
Any pointers on how to resolve this issue will be appreciated.
Figured out the problem. Couple of issues:
In the CF deployment manifest make sure the system domain property
is <BOSH_VPC_SUBDOMAIN>.<BOSH_VPC_DOMAIN>. That is if you have
reserved cf.example.com for cloud foundry PaaS. Make sure
cf.example.com is what system_domain property in your cloud
foundry deployment manifest refers to. Infact example.com should
not appear in your deployment manifest anywhere without cf..
Through out the deployment manifest it is always cf.example.com
Do not use '#' in any of the passwords within the deployment
manifest. I have logged a bug for this in cf-releases:
https://github.com/cloudfoundry/cf-release/issues/527
I have used bosh-lite to deploy a single node cloudfoundry in my development environment. After deployment, I run the bosh vms, and it returns the vms list:
+------------------------------------+---------+---------------+--------------+
| Job/index | State | Resource Pool | IPs |
+------------------------------------+---------+---------------+--------------+
| api_z1/0 | running | large_z1 | 10.244.0.138 |
| etcd_leader_z1/0 | running | medium_z1 | 10.244.0.38 |
| ha_proxy_z1/0 | running | router_z1 | 10.244.0.34 |
| hm9000_z1/0 | running | medium_z1 | 10.244.0.142 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 | 10.244.0.10 |
| loggregator_z1/0 | running | medium_z1 | 10.244.0.14 |
| login_z1/0 | running | medium_z1 | 10.244.0.134 |
| nats_z1/0 | running | medium_z1 | 10.244.0.6 |
| postgres_z1/0 | running | medium_z1 | 10.244.0.30 |
| router_z1/0 | running | router_z1 | 10.244.0.22 |
| runner_z1/0 | running | runner_z1 | 10.244.0.26 |
| uaa_z1/0 | running | medium_z1 | 10.244.0.130 |
+------------------------------------+---------+---------------+--------------+
But when I try to use "cf api https://api.10.244.0.34.xip.io --skip-ssl-validation" to connect the cloudfoundry, it returns an error:
ConnectEx tcp: No connection could be made because the target machine
actively refused it.
The log information is very general (actually this is the exception from CF client which is written in .net), and doesn't provide useful information.
My question is, which VM handles the api command? And, where can I find the detail log in that VM?
api_z1/0 is handling the command. You can get its logs via the BOSH CLI itself: bosh logs api_z1 0 --all.
You probably also need to add the route to your local route table so that traffic to HAProxy container at 10.244.0.24 knows to go through the BOSH-lite VM at 192.168.50.4. Run bin/add-route or bin/add-route.bat from the root of your BOSH-lite repo.
upon deployment in production, I get this error , I don't understand where is coming from this 5.5.30... but I uninstalled the gem locally (oSX) and remotely (Debian) and reinstalled it... so it should be compiled with the latest libraries.. 5.6.19
here are both MySQL versions installed ...
on Debian
mysql -u root -p -e 'SHOW VARIABLES LIKE "%version%";'
Enter password:
+-------------------------+-------------------+
| Variable_name | Value |
+-------------------------+-------------------+
| innodb_version | 5.6.19 |
| protocol_version | 10 |
| slave_type_conversions | |
| version | 5.6.19-1~dotdeb.1 |
| version_comment | (Debian) |
| version_compile_machine | x86_64 |
| version_compile_os | debian-linux-gnu |
+-------------------------+-------------------+
on OSX
yves$ mysql -u root -p -e 'SHOW VARIABLES LIKE "%version%";'
Enter password:
+-------------------------+------------------------------+
| Variable_name | Value |
+-------------------------+------------------------------+
| innodb_version | 5.6.19 |
| protocol_version | 10 |
| slave_type_conversions | |
| version | 5.6.19 |
| version_comment | MySQL Community Server (GPL) |
| version_compile_machine | x86_64 |
| version_compile_os | osx10.7 |
+-------------------------+------------------------------+