Rails Engines with multiple databases - mysql

I am creating application in Ruby on Rails which is having many engines(for modularity).
I want different databases for each engine. How to configure this?
Database - MYSQL

There is a good explanation by the link http://www.blrice.net/blog/2016/04/09/one-rails-app-with-many-databases/

General approach is to take a look at the framework sources and decide can it be reused.
Let's take a look at activerecord/lib/active_record/railties/databases.rake (v5.0.7) first. For example on how db:create implemented.
We will see ActiveRecord::Tasks::DatabaseTasks.create_current.
Let's open ActiveRecord::Tasks::DatabaseTasks and take a look at
# The possible config values are:
#
# * +env+: current environment (like Rails.env).
# * +database_configuration+: configuration of your databases (as in +config/database.yml+).
# * +db_dir+: your +db+ directory.
# * +fixtures_path+: a path to fixtures directory.
# * +migrations_paths+: a list of paths to directories with migrations.
# * +seed_loader+: an object which will load seeds, it needs to respond to the +load_seed+ method.
# * +root+: a path to the root of the application.
#
# Example usage of DatabaseTasks outside Rails could look as such:
#
# include ActiveRecord::Tasks
# DatabaseTasks.database_configuration = YAML.load_file('my_database_config.yml')
# DatabaseTasks.db_dir = 'db'
# # other settings...
This way we are getting to following solution:
namespace :your_engine do
namespace :db do
task :load_config do
ActiveRecord::Tasks::DatabaseTasks.database_configuration = YAML.load_file("config/database_your_engine.yml")
ActiveRecord::Tasks::DatabaseTasks.db_dir = "db_your_engine"
ActiveRecord::Tasks::DatabaseTasks.migrations_paths = [ "components/your_engine/db/migrate" ]
ActiveRecord::Base.configurations = ActiveRecord::Tasks::DatabaseTasks.database_configuration
ActiveRecord::Migrator.migrations_paths = ActiveRecord::Tasks::DatabaseTasks.migrations_paths
# You can observe following values to see how settings applied.
# puts ActiveRecord::Base.configurations
# puts ActiveRecord::Migrator.migrations_paths
# puts ActiveRecord::Tasks::DatabaseTasks.database_configuration
# puts ActiveRecord::Tasks::DatabaseTasks.migrations_paths
end
desc "Create Your DB"
task create: :load_config do
ActiveRecord::Tasks::DatabaseTasks.create_current
end
end
end
The same approach for drop/migrate and other needed tasks.
It is good general rule - know you stack at least one level lower than your work with. Sometimes reading underlying sources much more helpful than direct answer.
I will update this answer while going forward with my solution...

Related

Rubocop not ignoring db/schema.rb file

Why is my db/schema.rb file not being ignored by rubocop?
.rubocop.yml
require: rubocop-rails
require: rubocop-performance
AllCops:
Exclude:
- 'db/**/*'
- 'config/**/*'
- 'script/**/*'
- 'bin/{rails,rake}'
- 'vendor/**/*'
- 'spec/fixtures/**/*'
- 'tmp/**/*'
- 'Gemfile.lock'
Rails:
Enabled: true
# Commonly used screens these days easily fit more than 80 characters.
Metrics/LineLength:
Max: 120
# Too short methods lead to extraction of single-use methods, which can make
# the code easier to read (by naming things), but can also clutter the class
Metrics/MethodLength:
Max: 20
Metrics/BlockLength:
ExcludedMethods: ['describe', 'context', 'FactoryBot.define']
# The guiding principle of classes is SRP, SRP can't be accurately measured by LoC
Metrics/ClassLength:
Max: 1500
# No space makes the method definition shorter and differentiates
# from a regular assignment.
Layout/SpaceAroundEqualsInParameterDefault:
EnforcedStyle: no_space
Naming/VariableNumber:
EnforcedStyle: normalcase
# Single quotes being faster is hardly measurable and only affects parse time.
# Enforcing double quotes reduces the times where you need to change them
# when introducing an interpolation. Use single quotes only if their semantics
# are needed.
Style/StringLiterals:
EnforcedStyle: double_quotes
# We do not need to support Ruby 1.9, so this is good to use.
Style/SymbolArray:
Enabled: true
# Most readable form.
Layout/AlignHash:
EnforcedHashRocketStyle: table
EnforcedColonStyle: table
# Mixing the styles looks just silly.
Style/HashSyntax:
EnforcedStyle: ruby19_no_mixed_keys
# has_key? and has_value? are far more readable than key? and value?
Style/PreferredHashMethods:
Enabled: false
# String#% is by far the least verbose and only object oriented variant.
Style/FormatString:
EnforcedStyle: percent
Style/CollectionMethods:
Enabled: true
PreferredMethods:
# inject seems more common in the community.
reduce: "inject"
# Either allow this style or don't. Marking it as safe with parenthesis
# is silly. Let's try to live without them for now.
Style/ParenthesesAroundCondition:
AllowSafeAssignment: false
Lint/AssignmentInCondition:
AllowSafeAssignment: false
# A specialized exception class will take one or more arguments and construct the message from it.
# So both variants make sense.
Style/RaiseArgs:
Enabled: false
# Indenting the chained dots beneath each other is not supported by this cop,
# see https://github.com/bbatsov/rubocop/issues/1633
Layout/MultilineOperationIndentation:
Enabled: false
# Fail is an alias of raise. Avoid aliases, it's more cognitive load for no gain.
# The argument that fail should be used to abort the program is wrong too,
# there's Kernel#abort for that.
Style/SignalException:
EnforcedStyle: only_raise
# Suppressing exceptions can be perfectly fine, and be it to avoid to
# explicitly type nil into the rescue since that's what you want to return,
# or suppressing LoadError for optional dependencies
Lint/HandleExceptions:
Enabled: false
Layout/SpaceInsideBlockBraces:
# The space here provides no real gain in readability while consuming
# horizontal space that could be used for a better parameter name.
# Also {| differentiates better from a hash than { | does.
SpaceBeforeBlockParameters: false
# No trailing space differentiates better from the block:
# foo} means hash, foo } means block.
Layout/SpaceInsideHashLiteralBraces:
EnforcedStyle: no_space
# { ... } for multi-line blocks is okay, follow Weirichs rule instead:
# https://web.archive.org/web/20140221124509/http://onestepback.org/index.cgi/Tech/Ruby/BraceVsDoEnd.rdoc
Style/BlockDelimiters:
Enabled: false
# do / end blocks should be used for side effects,
# methods that run a block for side effects and have
# a useful return value are rare, assign the return
# value to a local variable for those cases.
Style/MethodCalledOnDoEndBlock:
Enabled: true
# Enforcing the names of variables? To single letter ones? Just no.
Style/SingleLineBlockParams:
Enabled: false
# Shadowing outer local variables with block parameters is often useful
# to not reinvent a new name for the same thing, it highlights the relation
# between the outer variable and the parameter. The cases where it's actually
# confusing are rare, and usually bad for other reasons already, for example
# because the method is too long.
Lint/ShadowingOuterLocalVariable:
Enabled: false
# Check with yard instead.
Style/Documentation:
Enabled: false
# This is just silly. Calling the argument `other` in all cases makes no sense.
Naming/BinaryOperatorParameterName:
Enabled: false
# There are valid cases, for example debugging Cucumber steps,
# also they'll fail CI anyway
Lint/Debugger:
Enabled: false
# Style preference
Style/MethodDefParentheses:
Enabled: false
I know this is an old question, but in case anybody's still having a similar issue:
When specifying multiple extensions such as rubocop-rails and rubocop-performance, provide them as an array to the require: directive, e.g.:
require:
- rubocop-rails
- rubocop-performance
Also worth noting is that rubocop-rails now ignores db/schema.rb by default (since version 2.4.1).
In my case I added only
AllCops:
Excludes:
- config/unicorn.rb
- db/**
Style/Documentation:
...
and rubocop is worked
In case anyone has the same confusion.. In my case, this was not actually a Rubocop issue. Running rails db:migrate was causing schema to be recreated and the column positions adjusted.

Bazel: Run a command without an output

I am using bazel for building bare metal programs. I would like to run the unit tests generated by bazel on qemu.
qemu-system-* -some_args -kernel bazel-bin/whatever/generated.elf
I've tried to run those by creating my own rule in a '.bzl'-file, but it seems that outputs are mandatory on all the rule actions. Note, that I need to invoke different qemu commands with different arguments depending on the target architecture. I would like to pass those to the rule.
Is there a way to invoke a shell command without any outputs?
If needed, this is what I have so far (yet I'm not sure which parts are correct as bazel stops in the analysis phase):
# run_tests.bzl
===============
def _impl(ctx):
qemu = ctx.attr.qemu
machine = ctx.attr.machine
cpu = ctx.attr.cpu
target = ctx.attr.target
# The command may only access files declared in inputs.
ctx.actions.run_shell(
arguments = [qemu, machine, cpu, target],
command="$1 -M $2 -cpu $3 -nographic -monitor null -serial null -semihosting -kernel $4")
run_tests = rule(
implementation=_impl,
attrs = {"qemu" : attr.string(),
"machine" : attr.string(),
"cpu" : attr.string(),
"target" : attr.string(),},
executable = True
)
And my BUILD-File:
# BUILD
=======
load("//make:run_tests.bzl", "run_tests")
run_tests(
name = "portos",
qemu = "qemu-system-arm",
machine = "realview-pbx-a9",
cpu = "cortex-a9",
target = ":test_portos.elf"
)
cc_binary(
name = "test_portos.elf",
srcs = glob(["*.cc"]),
deps = ["//src:portos",
"#unity//:unity"],
copts = ["-Isrc",
"-Iexternal/unity/src",
"-Iexternal/unity/extras/fixture/src"]
)
You are almost there: yes, you need outputs, otherwise bazel has nothing to do. For the rule output, you probably want the test logs or tests results.
Skylark has support for writing test rules. Basically instead of setting executable = True, you would set test = True, and then your rule would create an executable that is the test, then you set ctx.outputs.executable to that executable. Then you can use the bazel test command with your rule.
See:
docs: https://docs.bazel.build/versions/master/skylark/rules.html#test-rules
example: https://github.com/bazelbuild/examples/tree/master/rules/test_rule
rule.test: https://docs.bazel.build/versions/master/skylark/lib/globals.html#rule.test

Templating MySQL's my.cnf for setup in Puppet

I have been tasked with templating MySQL's my.cnf in an attempt standardize the configuration amongst the slave databases using Puppet. Right now, I'm targeting the innodb settings.
Are there configuration options that can safely be calculated against hardware specifications such as memory, disk and procs?
You need facter.
puppet:/etc/puppet/modules/master/lib/facter$ cat disks.rb
#!/usr/bin/ruby
#require 'facter'
mount = `/bin/mount`
disks=Array.new
mount.split("\n").each_with_index { | disk,i |
unless disk.scan(/ext3|simfs|reiserfs|xfs/).empty?
d=disk.split[2]
disks.push d
disks.push ','
end
}
Facter.add('disks') do
setcode do
disks
end
end
`
and in puppet.pp i use facts $disks
#add disk check to zabbix
exec { "create_host":
command => "/bin/echo $fqdn $ipaddress $disks | do_work",
require => File["/root/ticket"],
subscribe => File["/root/ticket"],
refreshonly => true,
}
see "Adding Custom Facts to Facter" on puppet labs.
I'd be tempted to move the calculations into the erb file, for example the key_buffer_size is recommended to be set to 1/4 of the Systems RAM:
set-variable = key_buffer_size=<%= (memorysize.split(' ')[0].to_i * 1024) / 4 -%>M
there is no reason why you couldn't work on other variables available from Facter (number of processors etc) and come up with your own calculations to set other variables as above.
Remember ERB effectively provides a subset of Ruby so almost anything you can do in Ruby can be done in ERB.
puppet have the erb template, erb template can use the facter value ,like hostname or memor. and you can write you self facter shell script.

Regarding Mercurial Security + recursive checkins of subrepositories

this is going to be a long post...sorry upfront.
I'm trying to wrap my head around how to hold together "Repositories for each project branch", and what the impact of that would be on a team.
Right now, it appears that
Can recursively checkin code of
nested checkins although hg status
doesn't give much info on file
changes within nested repos
It
appears that I -- and every team
member who wants to work on the same
project -- has to hand edit their
subrepositoies' .hgrc files in order
to make the checkin as painless and
automated as possible.
Can
recursively checkin, but recursively
checkout is not supported.
Is that a correct analysis of Hg's capabilities?
I'm really hoping not, as that's a lot more stick-shift coding (ie command prompt fiddling all over the place), than the average dev team I've seen could handle, while remaining productive. As I've understood it, refactoring a single assembly would probably grind the team to a halt as they stop to edit the .hgrc files to add location, user and password. No?
And I really want to double check that Hg can't recursively pull? Sounds like such an omission, that I feel I must have missed something.
Thanks!
PS:
For the brave or foolish, (and in case it helps), the notes I've been keeping as I work around the problem of projects that reference library modules that reference other library modules, is as follows (note the ???? QUESTIONS??? interspersed in them...
MERCURIAL
# requires an .hgsub with a ref to either
# an Hg Repo for only one Bin...?
# a website download...is that possible?
# an svn repo that allow referencing just one folder in it
# eg: "BIN/A3rdParty = svn:^/BinCache/A3rdParty/bin"
LibA\
hg\
.hgrc
# ??? QUESTION ???
# does each user have to edit their own files by hand
# to allow automatic push/pull?
# "default = https://user:pwd#bitbucket.org/xact/liba"
# "default-push = https://user:pwd#bitbucket.org/xact/liba"
.hgsub
# Map of nested repos as follows:
# "BIN/A3rdParty = svn:^/BinCache/A3rdParty/bin"
# "EXT/LibA = https://bitbucket.org/xact/liba"
# "EXT/LibB = https://bitbucket.org/xact/libb"
LibA.sln
BIN\
[A3rdParty\SomeLib.dll]
EXT\
SRC\
LibA\LibA.csproj
# ...which References "..\..\BIN\A3rdParty\SomeLib.dll"
LibA.Tests\LibA.Tests.csproj
# ...which References "..\LibA\LibA.csproj"
LibB\
hg\
.hgrc
# ??? QUESTION ???
# does each user have to edit their own files by hand
# to allow automatic push/pull?
# "default = https://user:pwd#bitbucket.org/xact/libb"
# "default-push = https://user:pwd#bitbucket.org/xact/libb"
.hgsub
# that contains:
# "BIN/A3rdParty = svn:^/BinCache/A3rdParty/bin"
# "EXT/LibA = https://bitbucket.org/xact/liba"
# ??? QUESTION ???
# do end users add user/pwd info here? or in the
# nested repos .hgrc file?
LibB.sln
BIN\
[A3rdParty\SomeLib.dll]
EXT\
LibA\
hg\
.hgrc
# ??? QUESTION ???
# does each user have to edit their own files by hand
# to allow automatic push/pull?
# "default = https://user:pwd#bitbucket.org/xact/liba"
# "default-push = https://user:pwd#bitbucket.org/xact/liba"
LibA.csproj
# ...which References "..\..\BIN\A3rdParty\SomeLib.dll"
LibA.Tests\LibA.Tests.csproj
# ...which References "..\LibA\LibA.csproj"
SRC\
LibB\LibB.csproj
# ...which References "..\..\EXT\LibA\LibA.csproj"
LibB.Tests\LibB.Tests.csproj
# ...which References "..\LibB\LibB.csproj"
ProjA\
hg\
.hgrc
# ??? QUESTION ???
# does each user have to edit their own files by hand
# to allow automatic push/pull?
# "default = https://user:pwd#bitbucket.org/xact/proja"
# "default-push = https://user:pwd#bitbucket.org/xact/proja"
.hgsub
# that contains:
# "BIN/A3rdParty = svn:^/BinCache/A3rdParty/bin"
# "EXT/LibA = https://bitbucket.org/xact/liba"
# "EXT/LibB = https://bitbucket.org/xact/libb"
# ??? QUESTION ???
# do end users add user/pwd info here? or in the
# nested repos .hgrc file?
BIN\
[A3rdParty\SomeLib.dll]
EXT\
LibA\
hg\
.hgrc
# ??? QUESTION ???
# does each user have to edit their own files by hand
# to allow automatic push/pull?
# "default = https://user:pwd#bitbucket.org/xact/liba"
# "default-push = https://user:pwd#bitbucket.org/xact/liba"
LibA.csproj
# ...which References "..\..\BIN\A3rdParty\SomeLib.dll"
LibA.Tests\LibA.Tests.csproj
# ...which References "..\LibA\LibA.csproj"
LibB\
hg\
.hgrc
# ??? QUESTION ???
# does each user have to edit their own files by hand
# to allow automatic push/pull?
# "default = https://user:pwd#bitbucket.org/xact/libb"
# "default-push = https://user:pwd#bitbucket.org/xact/libb"
LibB\LibB.csproj
# ...which References "..\..\EXT\LibA\LibA.csproj"
# Important: note that it is same path offset
# as when within context of LibB.sln
LibB.Tests\LibB.Tests.csproj
# ...which References "..\LibB\LibB.csproj"
SRC\
ProjA\ProjA.csproj
ProjA.Tests\ProjA.Tests.csproj
I will try to answer some of your questions though I really think you should discuss this with us instead of doing a Q&A here.
Right now, it appears that
Can recursively checkin code of nested checkins although hg status doesn't give much info on file changes within nested repos
See hg status --subrepos or hg status -S for short.
It appears that I -- and every team member who wants to work on the same project -- has to hand edit their subrepositoies' .hgrc files in order to make the checkin as painless and automated as possible.
No need to put usernamed and passwords into the .hg/hgrc files -- you should instead configure caching of HTTP credentials in Mercurial.
Can recursively checkin, but recursively checkout is not supported.
Checkout, i.e., update, is recursive. When you do hg clone to get a local repository, then Mercurial will notice the .hgsub and .hgsubstate files and it will recursively clone the subrepositories referenced there.
And I really want to double check that Hg can't recursively pull? Sounds like such an ommission, that I feel I must have missed something.
Yes, you're missing how Mercurial knows which subrepositories you want. Please see the documentation on the wiki or the Kick Start guide.

Autoconf Produces configure with Broken Functions (ac_fn_set_status, ac_fn_exit)

I'm trying to set up autoconf for my project. I have everything working "properly" except that the ac_set_<...> functions are not being found in ./configure. They work fine in configure.status if I run it directly.
Specifically, I am having trouble with as_fn_set_status and as_fn_exit.
If I manually edit the config file and move the two functions to the top of the configure script, everything works fine.
To get to this point I:
Wrote configure.ac
ran autoreconf -i
ran ./configure
The resulting lines are something like:
./configure: line 1366: as_fn_set_status: command not found
There are 3-4 lines on which the error occurs.
Any ideas on what might be producing this effect? Here is my configure.ac:
##########################################
# Autoconf Configuration File for RPDB #
##########################################
# RPDB: An Object-Oriented Wrapper for Oracle's Berkeley Database (BDB/libdb),
# which is available at: http://www.oracle.com/technology/software/products/berkeley-db/index.html
###########################
# Init Autoconf >= 2.61 #
###########################
AC_CANONICAL_SYSTEM
AC_PREREQ(2.61)
AC_INIT([rpdb], [0.1.0], [asher#ridiculouspower.com])
AC_CONFIG_AUX_DIR([.])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_FILES([Makefile])
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE
#################################
# Check for Library Functions #
#################################
AC_FUNC_ERROR_AT_LINE
AC_FUNC_MALLOC
AC_CHECK_FUNCS([strdup])
################################
# Check for Working Compiler #
################################
AC_PROG_CC
AC_PROG_RANLIB
#########################
# Check for Libraries #
#########################
AC_SEARCH_LIBS([db_create], [db], [have_libdb=yes])
#######################
# "Root Sourcefile" #
#######################
# "Root Sourcefile" is only used nominally to specify base path
AC_CONFIG_SRCDIR([src/RPDB_Base/RPDB.h])
#######################
# Check for Headers #
#######################
AC_HEADER_STDC
AC_CHECK_HEADERS([stdlib.h string.h])
# If we found libdb then check for db.h - we need to have both or we throw an error
if test "x${have_libdb}" = xyes; then
AC_CHECK_HEADERS([db.h], [], [have_libdb=no])
fi
if test "x${have_libdb}" = xno; then
echo "------------------------------------------"
echo " Oracle's Berkeley Database (libdb) "
echo " library and header file is required to "
echo " build RPDB. Stopping... "
echo " Check 'config.log' for more information. "
echo "------------------------------------------"
(exit 1); exit 1;
fi
#####################################################
# Check For Type-Related Compiler Characteristics #
#####################################################
AC_C_CONST
AC_HEADER_STDBOOL
AC_TYPE_INT32_T
AC_TYPE_PID_T
AC_TYPE_SIZE_T
AC_TYPE_UINT32_T
AC_TYPE_UINT64_T
AC_TYPE_UINT8_T
###############################
# Generate Configure Script #
###############################
AC_OUTPUT
You cannot invoke any macros that have a non-empty expansion prior to AC_INIT. If you move the invocation of AC_CANONICAL_SYSTEM to be after AC_INIT, your problem should go away.
I had a simillar problem which drove me crazy and eventually found the problem:
I tried to compile an older project that provided its own m4-macros. In included m4-files (in the config subdirectory) there have been calls to AC_DEFFUN that provided a third argument.
I did not understand why this caused that problem but taking away the third argument helped.
Do you perhaps have different autoconf's installed. I think that function originates from the m4 macro: m4sugar/m4sh.m4. You could check that file to see if it has the function.
It should look something like:
[AS_REQUIRE_SHELL_FN([as_fn_set_status],
[AS_FUNCTION_DESCRIBE([as_fn_set_status], [STATUS],
[Set $? to STATUS, without forking.])], [ return $[]1])]dnl