> 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 <j...@cincura.net> 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 > Firebird-net-provider@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider ------------------------------------------------------------------------------ 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 Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
