On Mon, 2009-11-16 at 21:57 +0100, Emanuele Aina wrote:
> diff --git
> a/src/DbMetal/Generator/Implementation/CodeTextGenerator/CodeGenerator.cs
> b/src/DbMetal/Generator/Implementation/CodeTextGenerator/CodeGenerator.cs
> index bc3a7e2..206c6fd 100644
> --- a/src/DbMetal/Generator/Implementation/CodeTextGenerator/CodeGenerator.cs
> +++ b/src/DbMetal/Generator/Implementation/CodeTextGenerator/CodeGenerator.cs
> @@ -177,12 +177,12 @@ namespace
> DbMetal.Generator.Implementation.CodeTextGenerator
> implementation.WriteHeader(writer, context);
>
> // write namespaces for members attributes
> - foreach (var memberExposedAttribute in
> context.Parameters.MemberExposedAttributes)
> - WriteUsingNamespace(writer,
> GetNamespace(memberExposedAttribute));
> + foreach (var memberAttribute in
> context.Parameters.MemberAttributes)
> + WriteUsingNamespace(writer, GetNamespace(memberAttribute));
Opinions will vary, but I don't find long-named variables which are in
scope for 1 line to be all that useful. 'a' would work just as well as
'memberAttribute', and (even better) would likely be more resilient to
change.
(You don't need to make this change, I'm just mini-ranting. ;-)
Which brings us to...the actual cleanup:
> diff --git a/src/DbMetal/Parameters.cs b/src/DbMetal/Parameters.cs
> index 1b4845e..458d6ac 100644
> --- a/src/DbMetal/Parameters.cs
> +++ b/src/DbMetal/Parameters.cs
> @@ -266,52 +266,54 @@ namespace DbMetal
> { "provider=",
> "Specify {PROVIDER}. May be Ingres, MySql, Oracle,
> OracleODP, PostgreSql or Sqlite.",
> provider => Provider = provider },
> - { "dbLinqSchemaLoaderProvider=",
> - "Specify a custom ISchemaLoader implementation {TYPE}.",
> + { "schema-loader=",
> + "ISchemaLoader implementation {TYPE}.",
> type => DbLinqSchemaLoaderProvider = type },
I think some form of convention for parameters which take type names as
values would be useful. I'd consider a 'type' suffix, but we now have
--generate-type, so that doesn't really work.
More importantly, there is another "compatibility" requirement: .NET
SQLMETAL.EXE. Using the same parameter names as .NET gives two things:
1. Makes it easier to use DbMetal (we use the same options!)
2. Makes Mono's sqlmetal easier for me (we use the same options!) ;-)
For DbLinq extensions, this isn't as important, but this does
potentially (unfortunately) impact some of your more recent work. For
example, SQLMETAL has a /entitybase option which, as per recent
discussion, is pointless (entities are partial classes, why would you
ever need this?!), but we need to keep it anyway (and I'm glad to see
that you did).
Returning to the original point ("some form of convention"), I think
that options taking type names as values should start with --with, thus
instead of --schema-loader, we should use --with-schema-loader.
> - { "databaseConnectionProvider=",
> - "Specify a custom IDbConnection implementation {TYPE}.",
> + { "dbconnection=",
> + "IDbConnection implementation {TYPE}.",
Similarly, this should probably be --with-connection or
--with-dbconnection.
> type => DatabaseConnectionProvider = type },
> - { "sqlDialectType=",
> - "The IVendor implementation {TYPE}.",
> + { "vendor=",
> + "IVendor implementation {TYPE}.",
1. As per above, a --with prefix.
2. I hate the 'vendor' terminology, as it doesn't really make sense to
me. There is lots of "cross-pollination" in supported SQL, e.g. SQLite
supports SQL Server-style [...] quoting, plus `...` and "..." (to quote
DB column and table names, etc.), and accepting SQL Server's '@'
parameter prefix. I suspect you can write a fairly decent amount of SQL
queries that's identical between SQLite and SQL Server.
For this reason, I don't like the idea of tying "flavor of SQL" to
"vendor" or manufacturer. I prefer the term "dialect" (and am
considering doing a s/DbLinq.Vendors/DbLinq.Dialects/ in some future
version if insanity takes me).
So I'd prefer --with-sql-dialect.
> type => SqlDialectType = type },
> { "code=",
> "Output as source code to {FILE}. Cannot be used with
> /dbml option.",
> file => Code = file },
> { "dbml=",
> - "Output as dbml to {FILE}. Cannot be used with /map
> option.",
> + "Output as dbml to {FILE}.",
> file => Dbml = file },
Have you removed the /map restriction?
> { "language=",
> "Language {NAME} for source code: C#, C#2 or VB "
> +"(default: derived from extension on code file name).",
> name => Language = name },
> - { "aliases|renamesFile=",
> + { "aliases=",
I wonder if this should instead be --map (or have --map as an alias) --
SQLMETAL provides a /map option, and iirc renamesFile was originally
used for /map, so reverting this to /map would likely be best.
> - { "entityBase=",
> + { "entitybase=",
> "Base {TYPE} of entity classes in the generated code "
> +"(default: entities have no base class).",
> type => EntityBase = type },
> - { "entityAttributes=",
> - "Comma separated {ATTRIBUTE(S)} of entity classes in the
> generated code.",
> - attributes => EntityAttributes = attributes },
> - { "memberAttributes=",
> - "Comma separated {ATTRIBUTE(S)} of entity members in the
> generated code.",
> - attributes => MemberAttributes = attributes },
> + { "entity-attribute=",
> + "{ATTRIBUTE} for entity classes in the generated code, "
> + +"can be specified multiple times.",
> + attribute => EntityAttributes.Add(attribute) },
But to follow up...is there really a need for --entity-attribute? You
can just place the attributes on a partial class declaration, AND
SQLMETAL doesn't provide this option (no compatibility requirement), so
I don't actually see a need for this anymore.
Thanks for looking into this!
- Jon
--
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/dblinq?hl=.
