I have been messing around with how it will be best for my new application to represent the users table in the database.
I noticed a migration named like this:
20110512234640_devise_create_users.rb
Is that something that Device creates upon its install? Or can I just use a simpler users table migration that I'd write by hand?
How do people usually configure Devise and still be able to add on extra columns to the users table which their particular applications might need?
Thanks,
Alex
Usually you can create on more migration to add your own fields to Devise used table (this is to keep devise migration clear and simple)
You're right, it is an automatically generated migration by Devise which allows you to choose your Devise modules more easily since default modules are added to the migration and others are there too but commented.
Of course, you can use a written-by-hand user migration.
Personally, I use that generated migration to add my own extra fields. But using a custom user migration file is the same.
Related
Does anybody know whether there is a way to use default OpenIddict storage functionality in a project which doesn't use Entity Framework and has not empty DB?
I'm trying to integrate Openiddict server to my Web App. The app has a DB, but communication with it is done using classic ADO.Net. I tried to find a similar example in the openiddict-samples repository but unfortunately without result.
I know that I can implement my own TokenStore, ApplicationStore etc. and register them via extensions for OpenIddictCoreBuilder but I'd like to use the default implementations in case it's possible to do that with not empty DB and without EF or with EF but for Openiddict functionality only. My DB is quite big and it's not an easy task to migrate it to EF.
I tried to use code from existing examples but those didn't work in my case. What I found out is that it works with empty DB only, otherwise OpenIddict tables are not created.
So I would very appreciate for any advice or link to example which I should investigate more carefully. So to say make OpenIddict to create its tables automatically, under the hood.
P.S.: I of course can copy those tables from examples and include scripts for their creation in my app, but I'd like to use the built-in functionality as much as possible.
OpenIddict version: 3.1.1
It seems that for now there is no a built-in functionality to achieve the wanted behavior. The only way is to create own Stores and StoreResolvers for OpenIddict and migrate tables creation to any suitable solution: a set of sql scripts, some kind of migration (e.g. FluentMigration), etc.
For now OpenIddict out of the box supports EF and Mongo only. This implementations can be considered as examples for implementation of Stores and StoreResolvers.
Hi I'm on Symfony 5 and I'll like to generate php entities and update the scheme from a orm.xml file.
I think it worked before with doctrine:generate:entities command.
Any solution? Thanks in advance
The command doctrine:generate:entities was removed. The Doctrine ORM team does not encourage creating entities from existing schema and therefore deprecated that functionality in the ORM.
With the MakerBundle you can create entities, but as far as I know it won't create them from a schema, so you have to manually create each Entity, which admittedly can be annoying if you just want to generate them based on the existing schema anyway. Alternatively you can create a new "legacy" Symfony application (e.g. based on version 3.4 as this should still have the command), create the entities from the schema as described in the docs, and then copy the generated entities over into your project. You will likely also have to run a search & replace for AppBundle\Entity -> App\Entity.
My entire group is new to ASP.Net Core and I was the lucky one tasked with Authentication/Authorization. We have always used a DB first approach, and this is no different, we already have our DB all set up. The higher ups want to use our specific tables for all things Identity, but they also want to leverage the tools that ASP.Net Core gives.
This will be a multi-site app where there is one central database. Our current setup is close to what the scaffolding adds, but has some small differences.
I have read a ton of resources, but the vast majority all focus on the code first approach and I currently don't fully understand what I need and what is there for the code first approach. I have seen a couple of answers that recommend using the .ToTable and .Property inside of OnModelCreate. Is this the best option or am I better off creating my own stores and methods? I currently have a user model created and a store to go with it (based on this site). Is it best for me to try to expand that all the way out (don't full understand how to have it pull in roles and claims).
This is what our DB Schema currently looks like.
At this point we are creating our Roles and Claims via a db script. The only thing we will be using UI's for right now is a page that will let a site admin add users, and assign them roles, and any singular claims they need.
Any help or input would be greatly appreciated as I try to wrap my head around all of this. If I have left out any pertinent information please let me know. As I said with what I have now I can create a user and login, I just have no idea where to go from here (how to add roles and claims).
Here's how I think about it and the steps I would take to approach in solving this problem.
So Microsoft's implementation of Identity is an abstraction of the problem.
The Models that they provide and the Tables that are derived from them is their choice for the default implementation of the abstraction.
So essentially what you want to do is to plug in your models in to this abstraction.
To quickly generate these models from your database you might want to use scaffolding this will generate the DbContext and the Models, you will then have to configure the dbcontext to plug in your design.
And if you look at how you can create your own Identity Tables providing your own objects
here this can give you an idea of how to plug in your models/functions in to this abstraction.
You will most likely have to override the OnModelCreating method to configure the relationship of your tables.
I'm working on a multi-tenant MVC 4 application and I'm going with the one schema per customer approach. I'd like to run the database migrations in code when a customer signs up. Is this possible using EF 5/Code First Migrations?
So when a customer signs up, I'll create an account in dbo. I'll then check if their subdomain exists as a schema in the database, if not, I'll create the schema and ideally run the migrations.
Thanks!
Clarification
When I create the new schema for the customer in the database, I want to run the migrations for that new schema. So for example,
I'll have schema1.Products and schema2.Products.
If I'm getting it right what you want...
You could use something like this
var migrator = new DbMigrator(new Configuration());
if (migrator.GetPendingMigrations().Any())
migrator.Update();
Or even better you may want to create your own initializer - e.g. check these posts of mine...
What is the correct use of IDatabaseInitializer in EF?
How to create initializer to create and migrate mysql database?
The problem I see with your approach is that'd you'd have to 'separate' the account model/database - and the one that you're trying to migrate. Since you mentioned multi-tenant that may already be the case.
But I guess you could also crete the 'base entities' for accounts etc. - and then migrate the rest on top. That's a bit complex scenario - the model is created once (per connection) on start (first use) and cached from then on. So the only for that would be to restart reload, I think (don't hold my word for it, just thinking out loud here)
Not sure if this is what you're asking for, you can run code migrations from command line:
packages\EntityFramework.5.0.0\tools\migrate.exe Example.dll /startUpDirectory:Example\bin
So in theory you could call this whenever a new customer signed up.
I have two apps on Heroku and I would like them to use the same dedicated database. The problem is that this new app has the same models/tables than the other one.
My questions are:
Should I change the name for the tables on the new app?
If yes, what about the name of my models? Is it possible to map a model with a table with a different name? (Like User model with new_user table instead of user).
Any good advices on how to do this will be appreciated.
Thanks!
In general this is probably not as good an idea as it may seem. Rails is designed to assume it has 100% control over the database.
Even if you are able to get your tables separated and not colliding, you will still have challenges with the schema_migrations table. That table holds all the migrations for rails and would contain a mix of all migration records for both applications. This would confuse the apps whenever, for example, you tried to run rake db:rollback or other rake commands.
There could also be issues with having your schema.rb file potentially get out of synch between the two applications.
I'd recommend looking hard at the reasons you want to share the database and see if there are other ways to accomplish what you are trying to do. For example, you might consider using Active Resources to connect the applications restfully.