Hello I wanted to ask if, to import the .sql update (after a git pull) I have to assemble and merge with the bash file (app/db_assembler) or if it's ok if I just launch the worldserver.exe and he will do it
Thanks
Short answer
No, the worldserver process will NOT update your database.
You need to use the DB-assembler bash script, as the instructions say.
More details
This is different than in TrinityCore, where it is a feature of the worldserver process to update the database.
In AzerothCore this task is a responsability of an external script, written in bash, the DB-assembler.
The advantage of having an external script to do this task instead of the worldserver is:
You don't need to compile and run the worldserver if you only need to create the database (useful when using or developing tools that only need the DBs)
The DB assembler is able to generate a unique SQL update file per each DB (by merging all the single SQL update files), which can be useful for debugging or development purposes
In general, it is better to delegate different software components for different tasks, instead of having a monolith doing everything
You can also make your own merge script and apply manually. Or just merge with the db_assembler.sh then apply manually.
Else refer to Francesco's answer
Related
I have installed Flyway Software and trying to deploy code. I have a Scenario
I created a file V1_01_CREATE_TABLE.SQL to create a table.
Created a file V1_01_CREATE_PACKAGE.SQL - This package will hold code to insert a row into one of the columns in table created in step 1.
Created a file V1_01_02_ALTER_TABLE.SQL - This SQL will rename the column which was being referred in step2.
This will invalidate the package if I run 1, 2 & 3. How does FLYWAY handle such a situation? Does it understand object dependency?
As explained in the manual, Flyway simply passes your SQL scripts to the database to be executed, and records the success or failure of their execution.
Flyway has no interest or understanding of the content of your scripts. Flyway never looks at the content of those scripts. In that sense, there is no “intelligence” in Flyway.
Flyway is like the postal worker delivering your letters without opening the envelope. You are the author, and you take full responsibility for the logic and correctness of the SQL scripts. You are responsible for following the naming conventions so your scripts run in the correct order.
After initially creating its metadata table, Flyway makes very limited use of JDBC and SQL. Flyway does little more than make a connection to the database server, determine which of the scripts have yet to be run, and say to the database “Here, run this script, and this script, and then run this script.” while recording the success or failure of each run.
You should name your scripts in order they needs to be executed
V1.0.0_CREATE_TABLE.SQL
V1.0.1_CREATE_PACKAGE.SQL
V1.0.2_ALTER_TABLE.SQL
This will execute scripts in migrated
Our common workflow when creating a new sql migration script is
to write and execute every single statement in the developers local datatase schema. When finished, it's checked into the source control system.
Problem is: at the database scheme of the creating developer, the script is already "executed". For scripts not beeing reentrant - it would be convenient to have s.th. like Dbmaintain's maven task "markDatabaseAsUpToDatemaven".
Does Flyway have s.th. equivalent?
P.S.: Our current workflow (as a workaround) is as follows:
"mvn flyway:migrate" this file as an empty file (without content - so it never fails).
put the sql statments in, save & "migrate" again.
"mvn flyway:repair"
Thanks
While the workflow you describe sounds like it can do the job, you can achieve the same in a simpler and fully automated way: set cleanOnValidationError to true (on for dev!) and everytime the script changes, the DB gets recreated.
More info: http://flywaydb.org/documentation/maven/migrate.html#cleanOnValidationError
I am writing a installer for windows using NSIS. The installer gets few properties during installation and it needs to update one of the table in sqlite database that is bundled with the installer. Is it possible to update sqlite database file using NSIS?
It does not seem like there are any SQLite plugins.
Your options are:
Write your own plugin (included for completeness, but almost certainly not a real option)
Use nsExec to run SQLite commands via the command line interface. See discussion on NSIS forums
Write a small app to include with your installer that makes the required changes
Decision probably depends on how well you know the command line interface for SQLite vs. complexity of writing a small app to do what you want.
For #3, it would be similar to what you would do with a third party installer:
ReserveFile "myexe.exe"
...
SetOutPath $TEMP
File "myexe.exe"
ExecWait '"$TEMP\myexe.exe" /parameters"
alt option: http://sourceforge.net/projects/nsissqliteplug/
nsisSqlplugin::executeQuery "sqliteDatabase" "sql_query"
Limitations:
Currently the plugin executes only insert and update queries.
I use Scrum methodology and deploy functionality in builds every sprint.
There is necessity to perform different changes in the stored data (I mean data in database and on filesystem). I'd like to implement it as a PHP scripts invoked from console. But they should be executed only once, during the deployment.
Is there any way to implement it through app/console without listing it in the list of registered Console commands? Or is there any other way to implement runonce scripts?
DoctrineMigrations covers some part of my requirements, but it's hard to implement complex changes in Model. And it does not cover changes in files on the filesystem.
I don't think symfony has a facility for that, and besides, hiding the command is not the same as securing the command.
Instead, I would make the script determine if it has been run already (could be as simple as adding a version number to a file and checking that number before running) and stop if it detects it has already run before.
I have an ASP.NET web application that includes code for enforcing its own database schema ; this code runs on application start.
I've recently started using LINQ to SQL, and I've added a pre-build event to run SqlMetal on my database so that I get objects representing my db tables.
What would be really cool is if I could enforce the database schema in the pre-build event, and then run SqlMetal. As it is, if the schema changes (e.g. I add a field to a table), I have to (a) build and run the website once so that application start fires and the schema is enforced, and then (b) build it again so that SqlMetal runs.
So: What are my options for running code that lives in my web application, from the command line?
Here's what we do.
We have a local 1-click build that is required to be run before check in (an integration build also runs in a separate environment every check in...).
The NANT script will:
Rebuild the database from scratch using Tarantino (Database change management)
Clean & Compile
Copy DLLs to a separate directory
Run Unit Tests against the DLLs
We have a separate script for SQL Metal, but your question is going to have me look at inserting the call between steps 1 and 2. This way your database changes and linq generated files are always in sync.
You could either write a small program that use CodeDOM to interpret a file in your repository or directly call the compiler executable inside your pre-build event.
Using CodeDOM avoid any problems with having to know where the compiler executable is but if your code can't be contained in one file without any dependency it's unusable and calling the compiler, then executing the result is a better option.