Open GoogleCodeExporter opened 9 years ago
Original comment by stuart02
on 27 Nov 2008 at 2:09
Original comment by stuart02
on 28 Nov 2008 at 7:21
I vote for this as well. Maintaining structure between local dev db and
production
db is kind of a pain.
Original comment by mainstre...@gmail.com
on 2 Dec 2008 at 3:07
You're interested in sync between production to dev or the other way around?
Sync
structure, data or structure and data?
Original comment by ursache....@gmail.com
on 21 Feb 2009 at 8:04
edxactly
Original comment by lauber.p...@gmail.com
on 23 Feb 2009 at 7:34
Optional.
When I develop locally, I manually track my changes (ALTER TABLE) in some
separate file that I then have to
constantly go and update on the production server. Several bugs have been
logged due to inconsistent structure.
The data-sync between the two is less critial. There's another bug where
simply logging all ALTER statements
would be excellent.
Original comment by mainstre...@gmail.com
on 24 Feb 2009 at 2:42
Original comment by avenja...@gmail.com
on 14 May 2009 at 2:58
Original comment by avenja...@gmail.com
on 14 May 2009 at 4:28
I would love to have a tool for synchronizing two databases inside Sequel Pro.
Original comment by erik.joh...@gmail.com
on 4 Aug 2009 at 6:00
SQLyog (both editions... the paid Enterprise version and the free Community
version) has this feature, but it's
only available on Windows and Linux. It lets you copy structure and data or
just structure, and you can
optionally drop existing conflicting tables. You can also select which entities
(specific tables, events, triggers,
etc.) to copy. I'm attaching a screen shot of the copy dialog... you just
connect to both databases, select one of
them, and use the Copy to Another Host/Server command.
My Mac-based team does both types of copies all the time, and it'd be *great*
if Sequel Pro could take over
this function. It's the one function from the community yog that absolutely
cannot do without. As such, we
run yog in Wine (which works pretty well, actually).
Original comment by aikido....@gmail.com
on 19 Nov 2009 at 8:19
Attachments:
Original comment by stuart02
on 31 Mar 2010 at 12:10
Issue 439 has been merged into this issue.
Original comment by stuart02
on 16 May 2010 at 6:32
I've been using this: http://www.mysqldiff.org/
Original comment by fil...@mac.com
on 15 Jun 2010 at 7:54
I am in support of this as well. Somehow I missed this when creating my own
feature request for the same thing. So sorry, mods!
Original comment by aaro...@gmail.com
on 26 Sep 2010 at 8:58
Issue 846 has been merged into this issue.
Original comment by schlabbe...@gmail.com
on 26 Sep 2010 at 9:07
This would be an amazing feature to add. It's pretty much the _only_ reason
we're using Navicat.
Original comment by espad...@gmail.com
on 30 Sep 2010 at 1:39
Agreed - in fact juts being able to drag and drop tables from one open database
to another would be great (even if you don't have full data sync).
Original comment by SonsOThu...@gmail.com
on 30 Sep 2010 at 6:07
Issue 778 has been merged into this issue.
Original comment by schlabbe...@gmail.com
on 30 Sep 2010 at 7:02
Issue 962 has been merged into this issue.
Original comment by stuart02
on 29 Jan 2011 at 8:02
Yes, this will be a very nice feature, syncing db structures is an important
step in dev workflow.
Original comment by philippe...@gmail.com
on 14 Jun 2011 at 10:49
Such a feature looks like a big undertaking, but it would be awesome for people
who work in both local and remote environments, and don't want unidirectional
replication.
Some sort of difference view between two tables, where one could perform
operations such as replace and merge on whole tables, or cherry pick changes
row by row and column by column, would simply *kill* :)!
Original comment by lou...@gmail.com
on 12 Jul 2011 at 10:56
Is it more likely that you're copying/syncing from one database to another on
the same host? Or would copying/syncing to a database on another host also be
just as important?
Original comment by avenja...@gmail.com
on 12 Jul 2011 at 12:32
In my current setup, I have one local database and one on my remote host. They
become out of sync when a) I add new features and content on my local one and
b) users and admins occasion changes in the remote one.
Though syncing / copying on the same host would also ease the management of
test or temporary databases.
Original comment by lou...@gmail.com
on 12 Jul 2011 at 12:54
I think the primary use case has to be across hosts, but sync targets are the
easy part :)
Original comment by rowanb@gmail.com
on 12 Jul 2011 at 1:35
I mostly support what lou...@gmail.com has said, selecting/merging/etc changes
would be great, especially a view to see two tables at the same time (maybe
this feature should be requested separately) but for start a simple ability to
copy/update tables or whole DB to another host (or same) would be most
excellent :)
Original comment by marko.br...@gmail.com
on 13 Jul 2011 at 6:53
I would also like to vote for the copy to host/db feature. Not necessarily
true "synchronization", which is a little different from copies (see
mk-table-sync). As opposed to more sophisticated approaches, I would just say,
while having a given target table selected, opening a dialog that selects:
(a) A connected host
(b) A target database
and offers the options of:
(1) SCHEMA vs SCHEMA+DATA copy,
(2) a DROP TABLE IF EXISTS option.
Original comment by colin.mu...@gmail.com
on 1 Aug 2011 at 2:54
Issue 1155 has been merged into this issue.
Original comment by stuart02
on 20 Aug 2011 at 9:23
I also vote for this feature, especially like the person above me stated, "copy
to host/db feature. Not necessarily true "synchronization"".
Thanks!
Original comment by j...@fyrastudio.com
on 18 Nov 2011 at 7:33
FWIW: I'd love to see this in SequelPro, but in the meantime if you need to do
this you can run SQLYog via CrossOver. May work in vanilla Wine, but I haven't
tried that.
Original comment by chrisblo...@gmail.com
on 13 Jan 2012 at 12:39
Original comment by abhibeck...@gmail.com
on 24 Mar 2012 at 1:15
I need this as well. Thanks a ton
Original comment by yankeyho...@gmail.com
on 4 Jun 2012 at 8:42
Issue 1426 has been merged into this issue.
Original comment by rowanb@gmail.com
on 16 Aug 2012 at 2:40
I'd use this feature as well, but please careful not to make it useless by
forcing a table drop to synchronize only the structure....
It should be a "synchronize" on the structure (Alter), not the data.... and
like others, I don't care about the data, because there are other ways to
handle that, but managing a dev->staging->production DB cycle is impossible
without this and I currently use sqlYog for it
Original comment by susiebee...@gmail.com
on 1 Sep 2012 at 12:47
I'd love to see this too. All I really need is an automated way to dump a
remote DB and import it into a local DB and update structure (with an option to
just replace local entirely, etc.). A one-click approach to this would be
fantastic.
Original comment by riverbra...@gmail.com
on 17 Jan 2013 at 8:02
I'd really would love this option too!
Original comment by kpoelhe...@gmail.com
on 6 Feb 2013 at 3:21
Why is this low priority? IMO this is a must have... will continue to use
navicat until this is added
Original comment by justineg...@gmail.com
on 30 Jul 2013 at 10:35
Would also love this feature!
Original comment by gabssnake
on 21 Aug 2013 at 1:35
Would like to see this too. It's important that it be able to do a partial
sync though, I always have some server specific settings in a few places that
shouldn't get updated between DBs.
Original comment by jbrown...@gmail.com
on 7 Oct 2013 at 1:25
I don't know if this should be a separate idea (because I'm not sure I would
really want to use syncing to replicate a change to production or another
developer's database) but in my view, generating a migration script (SQL,
perhaps allowing the ability to customize around it so we can create scripts
for our applications; ie PHP) that includes changes since the last migration
date. Then we could drop that migration script in a migration folder, similar
to how Laravel does it, which the application can then migrate when it detects
a new change. I think that would work for the vast majority of application
developers and be a lot easier than syncing between databases; may be able to
leverage what is already tracked in the console.
Original comment by redc...@gmail.com
on 7 Nov 2013 at 9:41
I am getting ready to promote significant changes from development to
production (on the same host). In the absence of this feature, I've got 15
scripts, created during the development process, to run in hopefully an order
that works.
It would be nice if a Sequel Pro developer would add to this thread describing
the challenge to creating this feature. (This conversation shows six other
threads being "merged in" so it appears to be a frequently requested feature.)
Original comment by b...@heyjoynin.com
on 6 Mar 2014 at 11:13
The "duplicate database" menu option could even be extended to allow
overwriting of another connection's database. I want to periodically replace my
local (production) server with the live public version of the database,
structure and/or content.
Original comment by Sly.Kni...@gmail.com
on 7 Mar 2014 at 8:59
Issues are now kept at GitHub: https://github.com/sequelpro/sequelpro/issues/72
Please do not comment here.
This will be ignored and the issue will not be updated.
Original comment by schlabbe...@gmail.com
on 7 Mar 2014 at 10:25
Original issue reported on code.google.com by
lauber.p...@gmail.com
on 29 Oct 2008 at 9:32