I use llblGen to catalog my Oracle database and generate code so I can work all that entity goodness. Works great and is better than sliced bread. I then deploy that code to my client environment where i hope that they have the exact same Oracle schema. Couldn't llblGen run some checks for me to determine if the client db is not in accord with the source database used to generate the llblgen code? Wouldn't that be sweet? Locally when i work and i make a schema change (data type, new field, etc.) in my database if i don't refresh my llblgen catalog i'm asking for trouble. Likewise, after i refresh my llblgen catalog and generate new code I first try to compile it to make sure that i don't have any breaking changes. But when i deploy i typically don't have a chance to compile on the client machine. I'm envisioning a single method that i can call and llblgen will run down every rabbit hole in it's library and do some simple thing like a select * maybe and if it bails then list that for me.

Am I overstepping the bounds of what the software should do? Probably. but dang that would be helpful.

LLBLGen does not do that at the moment and I'd be surprised if it is something that we would support in the near future.

How can you get to the state where you are unsure of the schema of your customers' databases ? Are they in control of the database schema or are you ?

Matt

Both dbs can be identical. I make a change locally and test it out. I ask the customer to make the same change in their schema. I have no control over their schema. The way i find out if they made the schema change now is that my app breaks.

I can envision some code that selects each of the entities and then tries to fill them and notes where that does not work - for starters.

You need some way of keeping track of which schema changes have been applied to a database, and an automated way of making the changes - rather than relying on the customer to do it.

I use a database version number. This is stored in the DB to indicate which version it has got to, and is also hard coded into the application. As the app runs it compares the version numbers. If they are identical the application is allowed to run.
If the app number is bigger than the database number it prompts the user to upgrade the database using a utility which we also supply - this knows how to upgrade the schema from one version to the next. It also updates the version in the DB once the upgrade has run successfully.

If you do want to put something together to test the tables all of the required meta data (table names, field names, data types etc) is in the generated FieldPersistenceInfo classes in the DB specific project.

Matt

But is there an object that will let me enumerate all of the entities which llblgen has generated for me? Something of a higher level object above the table? I could envision using reflection to get at that info. I could also probably use C# to assess the oracle tables and fields to get at the true metadata to compare to what llblgen has.

VBAHole22 wrote:

But is there an object that will let me enumerate all of the entities which llblgen has generated for me? Something of a higher level object above the table?

Are you using Adapter or SelfServicing?

VBAHole22 wrote:

I could envision using reflection to get at that info. I could also probably use C# to assess the oracle tables and fields to get at the true metadata to compare to what llblgen has.

IMHO, this goes outside the scope of the OR/M. I would make a DB compare tool or even a file-diff with two scripts of both DBs. I think that is more accurate.

Self.

I believe you are correct about the compare tool accuracy. But the tool i'm envisioning will be a little more versatile as it will be in a unit test. I have studio and source C# code on the client env and it would be nice to get that instant feedback, especially when i would need to deploy to several diff. environments in a single day. Additionally I would not need to pare down the entire client db to only compare the tables my app is concerned with, my generated set of entities will represent the areas of the db that i care about.

I think you can cook a small tool, using the EntityType enum, you can create entityFactories from the enum, and then entityCollection using the entityFactory.

Then you can do your selects and see if anyone fails.

Hint: check the EntityFactoryBase class and its CreateEntityCollection() method.