> No. You talked about generator/identity columns. Possibly replacing the interface. I think I've lose the point in this.
> That's definitely not. You can have one generator for all tables (and it's even better). For "Even better" I have doubts. Especially for multithreaded inserts to different tables case. > That's definitely not. I'm talking about "generator creation", it should be hidden in the provider. Though names yes, user should be allowed to pick a naming scheme he wants. In case "one generator for all tables" user specifies one generator name for all tables and provider should check if it exists - nothing to do, if not it creates new. After that it binds the generator name to before insert trigger. > Well, the default initializers are using different path. Yep, I'm aware about this. First I've patched one code path. After merge the migration feature I needed to patch another code path, and resulting database had differences. On 1 October 2015 at 14:13, Jiří Činčura <j...@cincura.net> wrote: > On Thu, Oct 1, 2015, at 11:45, Геннадий Забула wrote: >> >Do you think the annotations will be better? >> Better than what? Your concern was about different naming schemes, I >> suggested how it can be resolved via column annotations and custom >> name providers. I don't know other options for this. > > No. You talked about generator/identity columns. Possibly replacing the > interface. > >> >How is the generator creation (if it does not exists) going to be handled? >> >Or are we going to leave that to manual change of Up method in migration? >> IMO generator creation is an implementation detail that user shouldn't >> bother about. Generator creation is a part of a table creation. > > That's definitely not. You can have one generator for all tables (and > it's even better). > >> >Do you have some more info for this. >> I'm sure that there were issues about identity columns. The current >> implementation CreateDatabaseIfExists doesn't create generators in any >> case, we patched sources to do that. Also, bool fields don't have >> CHECK IN (0, 1) annotation and so on. >> I need time to provide additional info for this. > > Well, the default initializers are using different path. These existed > before migrations. The code is different (and also the feature set). It > also works with EDMX and CF, while migrations are (currently) CF only. > > -- > Mgr. Jiří Činčura > Independent IT Specialist > > ------------------------------------------------------------------------------ > _______________________________________________ > Firebird-net-provider mailing list > Firebird-net-provider@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider ------------------------------------------------------------------------------ _______________________________________________ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
