One more question. Will this PR get merged: https://github.com/cincuranet/FirebirdSql.Data.FirebirdClient/pull/43 ?
On 6 December 2015 at 19:29, Геннадий Забула <zabulu...@gmail.com> wrote: >> 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
