pajo wrote:
Hi,
we're currently using
PostgreSQL 9.4.1, compiled by Visual C++ build 1800, 64-bit
npgsql 2.2.4.3
we definitively need to be able to change default converter for each project, setting converter for each field is just too error prone, we can't rely on fact that we'll set correct converter it can be easily missed and it could be hard to detect these type of errors.
You can specify a TypeConversion definition in the project settings. Specify one for a datetime field using the filters for a given type converter. In the project settings further specify that type converters have to be set automatically by setting 'auto assign type converter to field mapping' to true. If a field mapping then matches a type conversion, the designer will assign the type converter automatically.
In v4.2, this is done with any new / changed field. So existing mappings are left alone after you added a type conversion definition. If you have set it up once properly, any new fields you're adding will be covered.
If you want to assign them using different rules, you could add a simple plugin which traverses all field mappings and assigns type converters to field mappings if the field is a datetime field. You can run this plugin based on a designer event, e.g. project before save (see Tools menu).
For the same reason it would be great if we don't need to include converter directly to llblgen project, if we make change to converter we just need to upgrade llblgen stack and there is no need to change every project. On project level we would need to do this once for every project, we could live with that, but it would be much easier if we could control this dynamically.
The problem is that the DateTime objects coming from the datareader have 'Unspecified' as datetime type. So a type converter is needed for converting them to UTC (or another type if you want, e.g. through a custom type converter).
The designer doesn't require an up to date type converter if you want to use one at runtime with different code. The designer will simply assign the type of the type converter to the field mapping. So as long as that type name (+ namespace) is equal to the one used at runtime (and referenced by the generated code) it's OK. This means you can use 2 different dlls, one for the designer, and one for usage at runtime available through nuget. If the latter is updated with new code, the former doesn't need to be updated, as long as the type names/namespace (and strong name if you sign the assembly) are equal.
Does this help?