Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a PMC command that will list all DbContext types #15104

Closed
Ponant opened this issue Mar 21, 2019 — with docs.microsoft.com · 22 comments · Fixed by #15652
Closed

Add a PMC command that will list all DbContext types #15104

Ponant opened this issue Mar 21, 2019 — with docs.microsoft.com · 22 comments · Fixed by #15652
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported good first issue This issue should be relatively straightforward to fix. help wanted This issue involves technologies where we are not experts. Expert help would be appreciated. type-enhancement
Milestone

Comments

Copy link

Ponant commented Mar 21, 2019

I have 2 dbcontext and Get-DbContext complains that I need to provide one whereas the docs says that it will list the Lists available DbContext types.
it is a bit astonishing that this error occurs whereas one could use the CLI tooling which works with
dotnet ef dbcontext list


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

@ajcvickers ajcvickers transferred this issue from dotnet/EntityFramework.Docs Mar 21, 2019
@ajcvickers
Copy link
Contributor

Moved to product repo since this seems to be a bug.

@bricelam
Copy link
Contributor

Get-DbContext is the equivalent of dotnet ef dbcontext info, not dbcontext list.

@bricelam
Copy link
Contributor

Huh, the docs are wrong...

@ajcvickers
Copy link
Contributor

Submitted docs PR: dotnet/EntityFramework.Docs#1387

@Ponant What was your reason for wanting to list the DbContexts from the package manager console? (Asking to determine whether or not it's worth leaving this open to track doing it.)

@Ponant
Copy link
Author

Ponant commented Mar 25, 2019

Hi @ajcvickers , I was using it as I use VS so that saves me having a console window opened.
In any case, I would highly recommend to put a sentence or two saying that the cli tools are more complete, as it seems to be the case. Until now I thought PMC would be equivalent to the cli tool.

@ajcvickers
Copy link
Contributor

@Ponant Yes, but why did you want to list the contexts in the first place?

@bricelam
Copy link
Contributor

Note, tab-expansion works for the -Context parameters in PMC.

@Ponant
Copy link
Author

Ponant commented Mar 25, 2019

@ajcvickers because I wanted to list the contexts instead of looking up the file names. Yes tab-expansion works too but there is a time lag and it does not list all dbcontexts and it does not always auto-complete...

@ajcvickers
Copy link
Contributor

@Ponant Thanks! Putting this on the backlog.

@ajcvickers ajcvickers changed the title Get-DbContext is not listing all types Add a PMC command that will list all DbContext types Mar 29, 2019
@ajcvickers ajcvickers added this to the Backlog milestone Mar 29, 2019
@ajcvickers ajcvickers added type-enhancement help wanted This issue involves technologies where we are not experts. Expert help would be appreciated. labels Mar 29, 2019
@ErikEJ
Copy link
Contributor

ErikEJ commented Apr 24, 2019

@bricelam Considering this - what would the command name be? Get-DbContexts ??

@bricelam
Copy link
Contributor

In hindsight, Get-DbContext should have been named Get-DbContextInfo, and this one should be named Get-DbContext...

List-DbContext seems OK for now. As usual, we'll discuss the actual name ad nauseam in a design meeting.

@ErikEJ
Copy link
Contributor

ErikEJ commented Apr 24, 2019

I will give it a shot

@ErikEJ
Copy link
Contributor

ErikEJ commented Apr 27, 2019

How about a breaking change?

function Get-DbContext
{
    [CmdletBinding(PositionalBinding = $false)]
    param([string] $Context, [string] $Project, [string] $StartupProject)

    $dteProject = GetProject $Project
    $dteStartupProject = GetStartupProject $StartupProject $dteProject

    if ($Context)
    {
       $params = 'dbcontext', 'info', '--json'
       $params += GetParams $Context
    }
    else
    {
       $params = 'dbcontext', 'list', '--json'
    }

    # NB: -join is here to support ConvertFrom-Json on PowerShell 3.0
    return (EF $dteProject $dteStartupProject $params) -join "`n" | ConvertFrom-Json
}

@bricelam
Copy link
Contributor

👍 Definitely worth discussing

@ErikEJ
Copy link
Contributor

ErikEJ commented Apr 30, 2019

I will await the discussion outcome

@bricelam
Copy link
Contributor

You don't have to; we can merge it however you send the PR. After discussing, we're happy to do the rename/combine/split ourselves.

@ErikEJ
Copy link
Contributor

ErikEJ commented Apr 30, 2019

OK, I will investigate how I can get it tested (manually)

@ErikEJ
Copy link
Contributor

ErikEJ commented May 4, 2019

@bricelam Any hints on how to get this tested?

@ErikEJ
Copy link
Contributor

ErikEJ commented May 5, 2019

Managed to get it tested - does this make sense or should the output be modified?

PM> Get-DbContext

fullName                                                      safeName          name              assemblyQualifiedName                                                                    
--------                                                      --------          ----              ---------------------                                                                    
Sws.ConfigurationProvider.Persistence.Azure.AzureDbContext    AzureDbContext    AzureDbContext    Sws.ConfigurationProvider.Persistence.Azure.AzureDbContext, Sws.ConfigurationProvider....
Sws.ConfigurationProvider.Persistence.Azure.AzureOtherContext AzureOtherContext AzureOtherContext Sws.ConfigurationProvider.Persistence.Azure.AzureOtherContext, Sws.ConfigurationProvid...


PM> Get-DbContext  -Context AzureDbContext
Microsoft.EntityFrameworkCore.Infrastructure[10403]
      Entity Framework Core 2.2.4-servicing-10062 initialized 'AzureDbContext' using provider 'Microsoft.EntityFrameworkCore.SqlServer' with options: None

providerName                            databaseName dataSource             options
------------                            ------------ ----------             -------
Microsoft.EntityFrameworkCore.SqlServer AzureData    (localdb)\MSSQLLocalDB None   

@bricelam
Copy link
Contributor

bricelam commented May 7, 2019

I think we can use a formatting file to make it display prettier... But I've never done it.

@bricelam
Copy link
Contributor

bricelam commented May 7, 2019

By default, I think we should just display safeName (but still let let scripts access the other properties)

ErikEJ added a commit to ErikEJ/EntityFramework that referenced this issue May 8, 2019
ErikEJ added a commit to ErikEJ/EntityFramework that referenced this issue May 8, 2019
@ajcvickers
Copy link
Contributor

Merged, but we may want to discuss in a design meeting.

@ajcvickers ajcvickers modified the milestones: Backlog, 3.0.0 May 8, 2019
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label May 8, 2019
@bricelam bricelam added the good first issue This issue should be relatively straightforward to fix. label May 31, 2019
@ajcvickers ajcvickers modified the milestones: 3.0.0, 3.0.0-preview6 Jun 5, 2019
@ajcvickers ajcvickers modified the milestones: 3.0.0-preview6, 3.0.0 Nov 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported good first issue This issue should be relatively straightforward to fix. help wanted This issue involves technologies where we are not experts. Expert help would be appreciated. type-enhancement
Projects
None yet
4 participants