Re: [Firebird-net-provider] 4.9.0 beta 1 release

[Геннадий З. <zab...@gm...>]

> Do you think it should throw exception? I would rather let that for
> Firebird. Somebody might tweak the script or something like that.

> I know you proposed hashing the name, but that's not reasonable general
> solution. The database would look gibberish for outside view. Nobody
> would know what's what.

I think the earlier it will be thrown the better. Also, in exception
message you can include text or/and link about workaround of this FB
limitation. It will be a good convenience for library users.

As for hashing, agree, when we implemented this solution I missed the
possibility to specify custom short names for tables.

> > 4. Also, I don't see where IFbMigrationSqlGeneratorBehavior can be
> > injected from client's app code.
> In ctor.

Ctor of what?

> Agree. I'd like to first see somebody outside implement other behavior.
> Then we can talk about what to extract - i.e. the system tables logic
> etc.

In specified links, I've provided my implementation of generator-per-table.


On 5 December 2015 at 17:54, Jiří Činčura <ji...@ci...> wrote:
>> 1. readonly IFbMigrationSqlGeneratorBehavior _behavior;
>> Is used only in migration operations DropColumn/AlterColumn, not used
>> in AddColumn.
>
> The AddColumnOperation calls Generate method for ColumnModel and this
> method handles the identity stuff. Or do you mean something else?
>
>> 2. We have additional implementation of Check in (0,1) for boolean
>> fields like implemented in SsdlToSql.cs
>
> Good idea. Added. (Testing it as we speak.)
>
>> 3. CreateItemName function doesn't support names longer than 31
>> character.
>
> Do you think it should throw exception? I would rather let that for
> Firebird. Somebody might tweak the script or something like that.
>
> I know you proposed hashing the name, but that's not reasonable general
> solution. The database would look gibberish for outside view. Nobody
> would know what's what.
>
>> 4. Also, I don't see where IFbMigrationSqlGeneratorBehavior can be
>> injected from client's app code.
>
> In ctor.
>
>> 5. I think the generator creation code in
>> DefaultFbMigrationSqlGeneratorBehavior will be copied to a possible
>> new implementation, so it is better to split logic. See base class:
>
> Agree. I'd like to first see somebody outside implement other behavior.
> Then we can talk about what to extract - i.e. the system tables logic
> etc.
>
> --
> Mgr. Jiří Činčura
> Independent IT Specialist
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider