Installation with existing database?

[cjaoude]

How does one go about using this package with an existing app/database. Seems to be only good for a brand new database.

?

[akazorg]

You can really hook Voyager to an existing database, that's one of the main proposes of the project.

The only concern is table name collision, so if your database use one of this table names, it will collide:

- categories
- data_rows
- data_types
- menu_items
- menus
- pages
- password_resets
- permission_groups
- permission_role
- permissions
- posts
- roles
- settings
- translations
- users

But there are good news! This issue is being resolved. I know @abdgad was working on that. Any progress?

[cjaoude]

...half of them every app has, so not really usable with an existing project as is.

[akazorg]

Well, at this time is unusable, indeed. Watch for the repo changes, this will be sorted out soon, since many users, like you, have this requirement.

[abdgad]

I will be looking out for the best way to solve this issue.

[cjaoude]

add-column migrations and/or namespacing?

[gnovaro]

SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'avatar' (SQL: alter table users add avatar varchar(255) null after
email, add role_id int null after id) in new installation

[mattmurtaugh]

Is there any update on this? I would like to use this to manage my project, but I am already using categories on my site.

[nugrahawahyu]

Is there any update on this?

[akazorg]

Not yet @nugrahawahyu

[lancepioch]

Labels: question, in progress, help wanted

[mindbits]

wouldn't it be the easiest way to just namespace all voyager table eg "tcgvoyager_"? We are doing it the other way around now namespacing our tables but it still does get mildly confusing looking at the show tables output or at /admin/database and not being able to differentiate between voyager's and our own tables

[fletch3555]

We can't just prefix our tables as it would require adding a new database configuration, which further complicates an already complex install process further. Without doing it as a prefix in the database config, we would have to define it in the $table property on the model which is counter-intuitive.

I completely understand the desire for this, but it's more complicated than you think. We're working on it, but are always open to suggestions.

[handiwijoyo]

Close this due inactivity.

[u01jmg3]

How can you close this issue when it is not rectified? There is inactivity because as @fletch3555 has said, they are working on a fix.

I assume the issue will be closed when code is committed against the issue - this then gives us users a reference point as to what has occurred.

[handiwijoyo]

Sorry my bad, I will keep this open for now until somehow we add table prefix. We definitely need that despite of the pros and cons.

Ref #1447

Note: I added this to 1.1 milestone for now.

[jhm-ciberman]

I think that the voyager migrations are runing before my migrations. So, they try to change the "users" table that does not exists already.

vagrant@flounder-web:~/code$ php artisan migrate
Dropped all tables successfully.
Migration table created successfully.

   Illuminate\Database\QueryException  : SQLSTATE[42S02]: Base table or view not found: 1146 Table 'homestead.users' doesn't exist (SQL: alter table `users` add `avatar` varchar(255) null default 'users/default.png' after `email`, add `role_id` int null after `id`)

  at /home/vagrant/code/vendor/laravel/framework/src/Illuminate/Database/Connection.php:664
    660|         // If an exception occurs when attempting to run a query, we'll format the error
    661|         // message to include the bindings with SQL, which will make this exception a
    662|         // lot more helpful to the developer instead of just the database's errors.
    663|         catch (Exception $e) {
  > 664|             throw new QueryException(
    665|                 $query, $this->prepareBindings($bindings), $e
    666|             );
    667|         }
    668|

  Exception trace:

  1   Doctrine\DBAL\Driver\PDOException::("SQLSTATE[42S02]: Base table or view not found: 1146 Table 'homestead.users' doesn't exist")
      /home/vagrant/code/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:144

  2   PDOException::("SQLSTATE[42S02]: Base table or view not found: 1146 Table 'homestead.users' doesn't exist")

      /home/vagrant/code/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:142

  Please use the argument -v to see more details.

[fletch3555]

@jhm-ciberman, that's unrelated to this issue. Laravel runs all migrations in date-order, so if you've changed the date on the default User migration or removed it and created your own, you'll have to backdate it to before Voyager's migrations as Voyager expects the default create_users_table migration to exist.

[mmubasharsheikh]

Hello friends, I'm already using spatie/permisisons with my application and I was about to go live with my forums and thought about voyager to integrate as my admin dashboard but after installation when tried to migrate I got an exception due to collision with my existing tables. Unfortunately, Voyager is useless with an existing application for now as this issue is opened from about last 2 years but no one solved it. Can some please fix this headache? Or this repo is useless for an existing product? If yes then @the-control-group please clearly mention it in the documentation so people wouldn't waste their precious time with this.

The solution is to add prefixes to your tables.

[erickhavel]

Or this repo is useless for an existing product? If yes then @the-control-group please clearly mention it in the documentation so people wouldn't waste their precious time with this.

👍 This...

[temperatio]

Any update about this? Is almost impossible install this into an existing app, the table names are too usual so it will collide a lot of times

[ekpono]

I am getting Illuminate\Database\QueryException : SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint (SQL: alter table user_roles add constraint user_roles_user_id_foreign foreign key (user_id) references users (id) on delete cascade) I am guessing because my existing users table ID is a string. Voyager is good but not to existing project

[byron-perez]

any update on this topic?

[Xplosive06]

Spent a lot of times with 'Syntax error or access violation: 1071' first, then this error.

This package looks great but definitely a headache to use on an existing project.

Have to uninstall everything and use something else.

[emptynick]

Spent a lot of times with 'Syntax error or access violation: 1071' first, then this error.

That's mentioned in our readme.

[chadidi]

Is this issue resolved yet?

[fletch3555]

@chadidi there really isn't anything to fix here... we've made improvements to the install process since this was first opened ~3 years ago.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you have further questions please ask in our Slack group.