I am having trouble getting quarkus.flyway.placeholders working in my Quarkus app.
I have this line defined in my application.properties file
quarkus.flyway.placeholders.myuser=my_user
in my sql file I have this line
GRANT DELETE, INSERT, SELECT, UPDATE ON survey.answers TO ${myuser};
the error I'm getting is
org.flywaydb.core.api.FlywayException: No value provided for placeholder: ${myuser}. Check your configuration!
Here are the things I've tried:
upgraded to Quarkus 1.13.6.Final
Tried setting
quarkus.flyway.placeholder-prefix=#[
quarkus.flyway.placeholder-suffix=]
As shown in the integration test:
https://github.com/quarkusio/quarkus/tree/main/integration-tests/flyway
Thank you
Matthew
I see you have a typo in your configuration or sql script.
With the following settings:
quarkus.flyway.placeholder-prefix=#[
quarkus.flyway.placeholder-suffix=]
In your sql file the placeholder should be defined as a #[myuser], not $[myuser]
You can also change the placeholder-prefix definition in your application.properties file to support prefix you already have in the sql file.
At one time I have two flyway users.
quarkus.flyway.owner this one has create privileges
quarkus.flyway.user this one has fewer privileges.
This item was not associated with the user role.
quarkus.flyway.placeholders.myuser=my_user
After changing it to quarkus.flyway.owner.placeholders.myuser=my_user
it started working.
Related
I'm trying to run a migration script in a Micronaut app configured with Flyway integration. The app runs as expected and applies the migration scripts without any Flyway placeholders. However, whenever I add a Flyway placeholder to a migration script the application does not start anymore due to a FlywayException:
org.flywaydb.core.api.FlywayException: No value provided for placeholder expressions: ${my_placeholder}. Check your configuration!
I've tried to configure the placeholder in application.yml using the Micronaut Flyway placeholders configuration property (as described here https://micronaut-projects.github.io/micronaut-flyway/latest/guide/index.html#io.micronaut.configuration.dbmigration.flyway.FlywayConfigurationProperties) but the placeholder simply isn't picked up. The application.yml file looks like this:
flyway:
datasources:
default:
locations: classpath:migrations
placeholders:
my_placeholder: "some value"
I've also tried creating a flyway.properties file with the placeholder defined according to what is described in this SO answer https://stackoverflow.com/a/9420671/2185719 but that did not work either
# flyway.properties
flyway.placeholders.my_placeholder=some value
While debugging Flyway startup (specifically in PlaceholderReplacingLine) I noticed that the placeholderReplacer object held a placeholder where the _ (underscores) had been replaced by - (dashes). Changing my_placeholder to my-placeholder in the migration script fixed the issue.
When I try to delete a class using the "Remove" option in the Jade class browser, I get the error:
"Class xxx cannot be deleted because:
Classes in an SDS Primary database cannot be deleted from the current schema context".
How can I remove a class?
In the context of an SDS environment, you need to version the schema before you can remove a class (using the 'Remove' option via the IDE for the latest schema version).
The re-org used to transition schema versions is then replayed on the SDS environment, as part of which its cached metadata is refreshed to reflect structural changes. I believe class removals is included with this (even if there's no persistent instances), because it'd need to discard the redundant class number.
You will want to use the Jade Schema Loader, with a command file.
According to the JADE Schema Load User's Guide, the syntax for the command file is:
JadeCommandFile
JadeVersionNumber 7.1.00
Commands
Delete Class ErewhonInvestmentsModelSchema::TenderSale
And you load it on your database server using:
jade.exe schema=RootSchema app=JadeSchemaLoader path=d:\jade\system ini=d:\jade\myjade.ini startAppParameters commandFile=d:\temp\DeleteClass.jcf loadStyle=currentSchemaVersion
Be sure to shutdown your database before running the command, or it will not run.
In my application I enable Code First Migrations with some migrations, Also I use SQL Server Compact for integration test.
When I run my tests, Entity Framework create an empty database and tries to run migration on that empty database and thrown The specified table does not exist.
Based on this report I think usage of Migration in Entity Framework 6 has changed.
I test all Database Initializer with Context.Database.Create(); but in all case tabale's never created.
I don't know that this is EntityFramework's bug or not, but when I made rename the namespace of Migration Configuration class from default (Projectname/Migrations) to any none default name, migration works well.
Context.Database.Create() will not execute migrations! It only creates empty db. To Update database from code to latest version you need to use DbMigrator.Update method:
var migrator = new DbMigrator(new MyMigrationsConfiguration());
migrator.Update();
Alternatively you might use MigrateDatabaseToLatestVersion
Database.SetInitializer(new MigrateDatabaseToLatestVersion<BlogContext, Configuration>());
It is described in details here: http://msdn.microsoft.com/en-us/data/jj591621.aspx#initializer
In case someone still struggles to fix the issue.
The code that follows works for me: add-migration MyFirstMigration
Meanwhile add-migration "MyFirstMigration" with the migration name ramped in quote doesn't work.
There may be previous migration files which the ide may be referring to mostly likely due to caching.
Drop backup and drop target database if it exists, and drop the migration folder.
Now add the migration and you will be good to go.
It does happens when adding model and running add-migration command.
Here is the simplest cause of this issue:
Add a newly added model property into IdentityDbContex class.
Here are the steps:
create model
add property into IdentityDbContex class
run add-migration
update-database
I have a spring boot application that uses the actuator, auto-configuration and JPA. I want to be able to use an in-memory DB in my test profile, a MySQL DB configuration during development and a separate production DB configuration when the app is deployed in production. Presumably from the java command line I should be able to specify the environment and the right configuration file or config block in application.properties (or .yml) will be picked up.
I have not found a good post with example describing how to do this switching so I thought I'd ask if anyone has a good example. My main aim is to pre-define the spring.datasource and spring.jpa properties at build time and then at run-time switch the app config per environment "dynamically" using the java command line argument. Secondary goal would be to do the same with the management configurations, etc.
Thank you.
Thanks to #Richard for the mention of spring.profiles.active JVM variable. Since my question was specific to the way Spring Boot does this and since there is much more to the answer, I am inclined to answer this myself and include all the details of how I arrived at the answer in the hopes that it will save others time.
First, you can indeed pick the correct profile on the java command line by adding -Dspring.profiles.active=profile_name when you are running your Spring Boot app. (this is assuming your deployment preference is an uber jar with embedded container - Tomcat in my case)
I wanted to leave MySQL datasource configurations under the default profile and put H2 in-memory datasource configuration under a test profile. However, the way Spring Boot picks the right datasource based on profile is not so obvious. Even though I had MySQL details under the default profile and I had the in-memory H2 datasource details under the test profile, it would still pick H2 as the datasource even when spring.profiles.active was omitted from the command line. This was contrary to my assumption that default profile will be picked, well, by default :-)
I ended up having to put H2 configuration under the default profile and then create a local profile that included the MySQL datasource configuration. Here's what I ended up with in my application.yml
spring:
profiles: default
spring:
datasource:
driverClassName: org.h2.Driver
url: jdbc:h2:mem:sampletest;MODE=MySQL
---
spring:
profiles: test
spring.jpa:
hibernate:
ddl-auto: create-drop
---
spring:
profiles: local
spring.datasource:
driverClassName: com.mysql.jdbc.Driver
url: jdbc:mysql://127.0.0.1/sampledev
username: sample
password: sample
spring.jpa:
hibernate:
dialect: org.hibernate.dialect.MySQLInnoDBDialect
ddl-auto: update
This worked. I was able to switch between default profiles and the local profile by omitting or adding the -Dspring.profiles.active=local on the java command line. Because test profile inherits from default it is also using H2
One more nuance: I added ddl-auto: create-drop to the test profile which uses the in-memory DB to facilitate automatic table creation / teardown for unit tests. But for the local profile which uses MySQL I changed it to update. Implication being that for the local profile I have to first create the database outside of the application.
this article shows how to use spring profiles, available in spring 3.1 and later. It will do exactly what you want.
http://chariotsolutions.com/blog/post/spring-3-1-environment-profiles-2/
set a JVM variable like this: spring.profiles.active=development
then in your configuration xml you can wrap environment specific xml with the profile tags
<beans profiles="development">
<bean id="dataSource" class="..."></bean>
<bean id="messagingProvider" class="..."></bean>
</beans>
You can also set the profile on annotation-driven classes with #Profile("development") at the beginning of the class. That class will only be autowired if the profile matches.
For unit tests you can set the active profile on a test class with #ActiveProfile(profiles = "test", "CI"), it will run using test and CI resources
I am using the TcmUploadAssembly utility in a post-build event but am receiving the following error from the tool.
Error 1 Name must be unique for items of type: Template Building Block
within this Folder and its BluePrint context. Source or sources of
conflict:
tcm:5-200-2048. C:\Projects\Project1\src\Tridion\TBBs\EXEC Compound
Templates
The TcmId given refers to the Assembly stored in Tridion which I would expect because that is what I am overwriting. In the past this "just worked". Am I missing something?
Notes:
My user is an admin
The Tridion instance is on my network so I am using credentials in context.
I have specified all settings via the command line (no config.xml is used)
Any ideas?
I would say check your Blueprint context (i.e. the Publication you are in). This error means you are trying to create the TBB, yet there is already an item with the same name probably somewhere down in the Blueprint child Publications.
Classic writing out the problem and the problem solves itself...
I discovered the folder is set in the AssemblyInfo as well and I had the folder set incorrectly on the command line (Blueprinting issue).
I ran into a second problem however, if I set uploadpdb:true on the command line I receive this error
Error 1 Could not write file: c:\Temp
Setting uploadpdb:false resolves the issue.