I'm looking for the best practice to do a mysql dump of a 8 tables in my Extbase CommandController.
Since an Extbase Repository handles only one specific table, it seems to be the wrong location to execute general mysql queries.
In which class should I put a raw mysql statement that affects multiple tables?
My issue is solved.
I made a BackupService class and run a mysqldump command with exec().
Related
I have a use case to distribute data across many databases on many servers, all in postgres tables.
From any given server/db, I may need to query another server/db.
The queries are quite basic, standard selects with where clauses on standard fields.
I have currently implemented postgres_FDW, (I'm, using postgres 9.5), but I think the queries are not using indexes on the remote db.
For this use case (a random node may query N other nodes), which is likely my best performance choice based on how each underlying engine actually executes?
The Postgres foreign data wrapper (postgres_FDW) is newer to
PostgreSQL so it tends to be the recommended method. While the
functionality in the dblink extension is similar to that in the
foreign data wrapper, the Postgres foreign data wrapper is more SQL
standard compliant and can provide improved performance over dblink
connections.
Read this article for more detailed info: Cross Database queryng
My solution was simple: I upgraded to Postgres 10, and it appears to push where clauses down to the remote server.
Say I have the following database hosts
core (host: a.b.c.d, dbaname: core, username: coreUser) with tables users, accounts and permissions
app1 (host: d.e.f.g, dbname: appdb1, username: appuser1)
app2 (host: h.i.k.l, dbname: appdb2, username: appuser2)
I would like core.users, core.accounts and core.permissions to be available as native tables on app1 and app2. I want to be able to mirror the exact table and inserts and updates on these tables should update the tables in the core. Is there a way to do this?
postgres_fdw can do the job.
The postgres_fdw module provides the foreign-data wrapper
postgres_fdw, which can be used to access data stored in external
PostgreSQL servers.
The functionality provided by this module overlaps substantially with
the functionality of the older dblink module. But postgres_fdw
provides more transparent and standards-compliant syntax for accessing
remote tables, and can give better performance in many cases.
FDW as you know stands for foreign data wrappers, it's used to connect external data sources to postgresql. In this case the external data source is another postgrsql database.
Yes, have a look at slony replication.
If you don't want to copy data then dblink extension might help you. It allows to call queries from one database to other. Combined with a function or a view could potentially be useful (although changes done to core would not be automatically reflected in "child" databases).
We have a series of modifications to a Postgres database, which can generally be written all in SQL. So it seems Flyway would be a great fit to automate these.
However, they also include imports from files to tables, such as
COPY mytable FROM '${PWD}/mydata.sql';
And secondarily, we'd like not to rely on Postgres' use of file paths like this, which apparently must reside on the server. It should be possible to run any migration from a remote client -- as in Amazon's RDS documentation (last section).
Are there good approaches to handling this kind of scenario already in Flyway? Or alternate approaches to avoid this issue altogether?
Currently, it looks like it'd work to implement the whole migration in Java and use the Postgres driver's CopyManager to import the data. However, that means most of our migrations have to be done in Java, which seems much clumsier. (As far as I can tell, hybrid Java+SQL migrations are not expected?)
Am new to looking at Flyway so thought I'd ask what other alternatives might exist with Flyway, since I'd expect it's pretty common to import a table during a migration.
Starting with Flyway 3.1, you can use COPY FROM STDIN statements within your migration files to accomplish this. The SQL execution engine will automatically use PostgreSQL's CopyManager to transfer the data.
I'm using PostgreSQL as the DB backend for a new Symfony2 + Doctrine2 project. I'd like to take advantage of some of the features of PostGIS, and as such have created a Postgres template for PostGIS.
Right now, I can't see how to tell Doctrine2 to use the PostGIS template instead of the default, looking through the Doctrine2 code hasn't lead me anywhere (to be honest, I'm struggling to figure out how it even works).
Is this even possible? If so, how?
One of your very basic problems is likely to be the fact that when you abstract, you lose low level control. To my knowledge template databases are not likely to be common concepts elsewhere. So you really have to drop to a lower level, connect to the postgres db manually and issue your CREATE DATABASE foo WITH TEMPLATE bar statement yourself.
I was used to work with Zend Db Table Relationships with MySQL. I declared $_dependentTables and $_referenceMap in the table classes as described in the manual. Then was able to work with functions findDependentRowset(), findParentRow() etc.
Now I use PostgreSQL, which is able to define the relations (REFERENCES) between tables right in the database.
The manual states:
Skip declaration of $_dependentTables if you use referential integrity constraints in the RDBMS server to implement cascading operations
what should be the case of Postgres. Despite this, I am not able to get it working. Unless I declare the referenceMap (but this shouldn't be needed!), I am still getting error:
No reference from table ... to table ...
The question is - is it possible to use references declared in Postgres in Zend Db, without (re-)declaring them in referenceMap? How - does ZF load it from Postgres to the referenceMap? If so, why I am getting the error?
My reading of the linked documentation is that these two address something different.
The DRI in the db recommendation is a recommendation to specify ON UPDATE CASCADE and ON DELETE CASCADE operations in the db rather than telling Zend to cascade.
What you are doing is something different, which is to use the referential integrity mapping to fetch related rows. In this case, it looks like Zend requires that you declare it.