Hi,

we have following situation, we're building modular app where each module is separate solution with it's own DAL. We control llblgen version through our nuget package so all modules uses same version (4.2.0.0 at the moment) and we're using postgresql driver. DAL is generated through designer. There are several developers working on each module and they all can make changes to DAL.

We have issues with default date time converter as we're getting unspecified kind when we're fetching data out of database and we want all times to be treated as utc. By quickly searching forum we found only suggestion to use typeconverter, but that doesn't seem practical in our situation.

What we would ideally like to achieve is to inject our own datetime converter, we could then add it to our package and developers working on modules don't need to know anything about it and they don't need to change anything to their DAL. Also it will be great if we can to this on driver level to reduce number of conversions (Converting from NpgsqlDate or NpgsqlDateTime).

Could you please post the PostgreSQL version and the NpgSql version?

By quickly searching forum we found only suggestion to use typeconverter, but that doesn't seem practical in our situation.

Which thread was that?

I might be missing something obvious, but In general TypeConverters can be written once and packed with your solution. I don't see a reason for it to be injected and dynamically used, in all cases a developer will need to set it in the designer for each field that needs its type to be converted. So as you build and deliver your application, code generation including typeConverters association would be delivered as well.

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.

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.

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?

Hi,

we were able to set it up as you suggested, it has it's own quirks when you're setting up new project, but once it's set it's fine.

Thank you for your help