Hi, Before starting on a coding mission I thought it wise to check to see if there is anything out there already...

We've customised the PersistenceInfo template for the adapter model so that the database name is no longer hardcoded into the Create*EntityBucket methods, instead the database name is picked up from config. This allows the DBSpecific assembly to be used against multiple db instances (dev, qa, loadtest, etc).

What I'm about to write is a utility that accepts a DbSpecific assembly and a database connection string and then checks that the two are compatible. I'll use the information generated into the PersistenceInfoFactory class to ensure that the objects in the given database are what the generated ORM layer expects.

Has anyone done something like this already (and willing to share the code)? The code will be pretty similar to the catalogue refresh performed by the TemplateStudio - any tips on how best to do this

Thanks, Stef

stef wrote:

Hi, Before starting on a coding mission I thought it wise to check to see if there is anything out there already...

We've customised the PersistenceInfo template for the adapter model so that the database name is no longer hardcoded into the Create*EntityBucket methods, instead the database name is picked up from config. This allows the DBSpecific assembly to be used against multiple db instances (dev, qa, loadtest, etc).

You can already do this with the standard templates. Please see "Using the generated code - Application configuration through .config files".

You can also force the name to be cleared, so the name in the connection string is used as the default catalog. See Using the generated code / Adapter / DataAccessAdapter functionality, SqlServer specific.

What I'm about to write is a utility that accepts a DbSpecific assembly and a database connection string and then checks that the two are compatible. I'll use the information generated into the PersistenceInfoFactory class to ensure that the objects in the given database are what the generated ORM layer expects.

Has anyone done something like this already (and willing to share the code)? The code will be pretty similar to the catalogue refresh performed by the TemplateStudio - any tips on how best to do this

I'm not sure if you need this, with the name overwriting code already build in

Otis wrote:

You can already do this with the standard templates. Please see "Using the generated code - Application configuration through .config files".

You can also force the name to be cleared, so the name in the connection string is used as the default catalog. See Using the generated code / Adapter / DataAccessAdapter functionality, SqlServer specific.

Thanks, a case of RTM

Otis wrote:

stef wrote:

What I'm about to write is a utility that accepts a DbSpecific assembly and a database connection string and then checks that the two are compatible. I'll use the information generated into the PersistenceInfoFactory class to ensure that the objects in the given database are what the generated ORM layer expects.

I'm not sure if you need this, with the name overwriting code already build in

What I'm after is a utility that checks whether or not the ORM and the database are in step. In particular, due to a somewhat cumbersome db change process, I'd like to know whether or not a particular database schema has all the database objects required by a specific version of the ORM and that these objects have the signature that the ORM expects.

The name overwriting doesn't give me this, I'd like to be able to tell the user at application initialisation that the database is not compatible, [and optionally what the incompatiblities are, e.g. for test environments].

Cheers, Stef

stef wrote:

Otis wrote:

stef wrote:

What I'm about to write is a utility that accepts a DbSpecific assembly and a database connection string and then checks that the two are compatible. I'll use the information generated into the PersistenceInfoFactory class to ensure that the objects in the given database are what the generated ORM layer expects.

I'm not sure if you need this, with the name overwriting code already build in

What I'm after is a utility that checks whether or not the ORM and the database are in step. In particular, due to a somewhat cumbersome db change process, I'd like to know whether or not a particular database schema has all the database objects required by a specific version of the ORM and that these objects have the signature that the ORM expects.

The name overwriting doesn't give me this, I'd like to be able to tell the user at application initialisation that the database is not compatible, [and optionally what the incompatiblities are, e.g. for test environments].

Hmm. That's not that easy I think... You've to grab all the persistence info objects from the persistenceinfofactory and check their data with the db.

Otis wrote:

Hmm. That's not that easy I think... You've to grab all the persistence info objects from the persistenceinfofactory and check their data with the db.

Thanks Otis, that's pretty much the conclusion I've come to. I'm creating a template to generate a new class in the DbSpecific assembly that will do this checking (since the PersistenceInfoFactory is an internal class). I'll check the persistence info properties against the results of querying the INFORMATION_SCHEMA.Columns view in SQL Server for the db object that the entity is based on. This will allow me to track missing objects, columns and any property mismatches.

Cheers, Stef