Previously (v2.6) I made a command line tool to generate a project, populate the catalogs, and generate the code.

Now, I'm trying to do the same for v3, but I am having trouble calling the right methods.

The piece I'm currently having problems with is these line of code:

 //Prepare for getting the catalog
            project.MapExistingTypeConverterInstances(configurationSettings.TypeConverters);
            Hashtable callBacks = new Hashtable();
            callBacks.Add(ProgressCallBack.SubTaskProgressInitCallBack, new SubTaskProgressInitCallBack(SubTaskProgressInit));
            callBacks.Add(ProgressCallBack.SubTaskProgressTaskCompletedCallBack, new SubTaskProgressTaskCompletedCallBack(SubTaskProgressTaskCompleted));
            callBacks.Add(ProgressCallBack.SubTaskProgressTaskStartCallBack, new SubTaskProgressTaskStartCallBack(SubTaskProgressTaskStart));
            callBacks.Add(ProgressCallBack.TaskProgressInitCallBack, new TaskProgressInitCallBack(TaskProgressInit));
            callBacks.Add(ProgressCallBack.TaskProgressTaskCompletedCallBack, new TaskProgressTaskCompletedCallBack(TaskProgressTaskCompleted));
            callBacks.Add(ProgressCallBack.TaskProgressTaskStartCallBack, new TaskProgressTaskStartCallBack(TaskProgressTaskStart));
            callBacks.Add(ProgressCallBack.SelectStoredProcsToRetrieveCallBack, new SelectStoredProcsToRetrieveCallBack(SelectStoredProcsToRetrieveHandler));

            SchemaFetchFlags fetchFlags = SchemaFetchFlags.Tables | SchemaFetchFlags.Views | SchemaFetchFlags.StoredProcedures;
            Hashtable retrievalProperties = new Hashtable();
            retrievalProperties.Add(CatalogElementRetrievalOption.ManualSelectSProcsFromSchema, false);
            retrievalProperties.Add(CatalogElementRetrievalOption.AutoDetermineSProcType, true);
            retrievalProperties.Add(CatalogElementRetrievalOption.UnattendedRetrieval, true);
            ArrayList catalogsPopulated = project.DatabaseDriver.PopulateSelectedCatalogs(callBacks, project.ConnectionElements, fetchFlags, retrievalProperties);
            //Show error list
            DisplayErrors(catalogsPopulated);
            //Add catalog to the project
            project.Catalogs.Add(catalogsPopulated[0]);

Actually there are two issues, the first is this line, which I cannot find an equivalent for:

  project.MapExistingTypeConverterInstances(configurationSettings.TypeConverters);

the other part is the actual schema retrieval and adding to the projects catalog.

Anyone has a hint on what methods to call?

The code to use is currently internal in classes inside the applicationcore assembly. We'll expose these methods when we'll release the cli refresher, but when that is hasn't been decided yet.

Otis wrote:

The code to use is currently internal in classes inside the applicationcore assembly. We'll expose these methods when we'll release the cli refresher, but when that is hasn't been decided yet.

Ok.

But I have an issue with this, since upgrading is no option for us until these are public. We are 16 developers that do not use the designer, but rely on our custom tool to make decisions for the mapping.

As a workaround, is it feasable to automate an upgrade from the 2.6 project file, to 3.0, and use the cli refresher in the SDK for v3 or similar, and then generate the files?

Just so I have made myself clear, our custom tool takes a server and schema name, reads the schema, populates the catalog, handles all the sequences,custom type mapping, naming conventions, and in the end, outputs nice and neat LLBLGen assemblies. This is to ensure that we all do things the same way, without having to add the llblgen project to the source repository.

gulhaugen wrote:

Otis wrote:

The code to use is currently internal in classes inside the applicationcore assembly. We'll expose these methods when we'll release the cli refresher, but when that is hasn't been decided yet.

Ok.

But I have an issue with this, since upgrading is no option for us until these are public. We are 16 developers that do not use the designer, but rely on our custom tool to make decisions for the mapping.

Ok. Keep in mind that in v3 licensing has changed: you need a license to run any applicationcore using assembly, so a clirefresher will require a license. In v2 this was a grey area where you could run a clirefresher/generator without a license (it technically didn't check for it). Could you elaborate a bit about the 'make decisions for the mapping' ? Your system (described below) sounds like it has to make sure the entity model stays close to the relational model, otherwise you'll run into situations where you have to make decisions, e.g. rename a navigator which has the same name as an inherited navigator.

As a workaround, is it feasable to automate an upgrade from the 2.6 project file, to 3.0, and use the cli refresher in the SDK for v3 or similar, and then generate the files?

I don't follow what you mean, sorry, as there's no cli refresher in the sdk at the moment. Or do you mean: we refresh in v2.6, then convert to v3 using the template, load that in v3 and generate code ? I wouldn't take that route in an automated system as it's not reliable in all cases, as the v2->v3 template can't make all the decisions. So it can be an upgrade to v3 results in some validation issues you have to fix in v3's designer.

Just so I have made myself clear, our custom tool takes a server and schema name, reads the schema, populates the catalog, handles all the sequences,custom type mapping, naming conventions, and in the end, outputs nice and neat LLBLGen assemblies. This is to ensure that we all do things the same way, without having to add the llblgen project to the source repository.

In v3 the project file is xml based, and designed to be sourcecontrol and merge friendly. Sharing the file is therefore not a problem anymore. Many things inside the designer are controlled by settings in the project file, which thus are equal for everyone using the project file.

What exactly do you mean with 'handles all the sequences': do you mean: it auto-assigns sequences to fields (as there's no connection between them in oracle) ? The rest is already handled by the designer. Code generation and compiling (also pre-code generation checkout from scc) can be done with an adjusted preset where you use a taskperformer which compiles your code after the code has been generated.

The thing is that in v3 validation has been added and things which were moved under the rug in v2 are now considered 'wrong' and could result in an error which you first have to fix.

The designer has had an event system since a long time btw, and you can bind plugins to these designer events, e.g. after project load, after entity add, which could automate things for you inside the designer.

Ok. Keep in mind that in v3 licensing has changed: you need a license to run any applicationcore using assembly, so a clirefresher will require a license. In v2 this was a grey area where you could run a clirefresher/generator without a license (it technically didn't check for it).

Regarding licensing, we have a license for each user that runs the generator.

Could you elaborate a bit about the 'make decisions for the mapping' ? Your system (described below) sounds like it has to make sure the entity model stays close to the relational model, otherwise you'll run into situations where you have to make decisions, e.g. rename a navigator which has the same name as an inherited navigator.

We have an old database schema, with many installations, with customization. So a subset is equal among everyone. Our core system uses the common tables, and the custom code generates a complete adapter model for the entire system, and uses that code. We also use LLBGen for other projects as well, so it is not all black and white. How we like to use LLBLGen is for every change in the database, we generate the entire project from scratch, and compile the DLL. We then add the new DLL's. But in between we have old sequence mappings which I have an XML file for, and modify the project. We also set naming conventions, like manytomany etc. In addition, we have a system for storing typeconverters in the DB, and generate those, and again, modifies the project before the code is generated.

The reasoning behind this, is that we actually do not need the complexity of the designer to make the dlls, and all the options in the designer are potential "policy" breakers.

I don't follow what you mean, sorry, as there's no cli refresher in the sdk at the moment. Or do you mean: we refresh in v2.6, then convert to v3 using the template, load that in v3 and generate code ? I wouldn't take that route in an automated system as it's not reliable in all cases, as the v2->v3 template can't make all the decisions. So it can be an upgrade to v3 results in some validation issues you have to fix in v3's designer.

LLBLGenPro_v3.0_SourceCode_20110107 contains a CLIRefresher. I was just thinking a way we could start using the v3 runtime libraries, was to create the v2.6 project as before, convert it, and generate code for v3, since the project behaves as we want it to.

In v3 the project file is xml based, and designed to be sourcecontrol and merge friendly. Sharing the file is therefore not a problem anymore. Many things inside the designer are controlled by settings in the project file, which thus are equal for everyone using the project file

Yes, I know, very good. But as we do not need it, I do not see a reason to start doing it.

What exactly do you mean with 'handles all the sequences': do you mean: it auto-assigns sequences to fields (as there's no connection between them in oracle) ? The rest is already handled by the designer.

You are spot on. we have a lot of them.

The designer has had an event system since a long time btw, and you can bind plugins to these designer events, e.g. after project load, after entity add, which could automate things for you inside the designer.

I know. But it does not comes close to the easy of starting a command, and 30 seconds later the dll's are finished. With no chance of doing anything out of the ordinary.

Out of the programmers here, none have ever had the need to open the designer, I bet just 1 or 2 have done, once. They are very happy with lllbgen, and the easy of use we have, and I do not want to change it.

gulhaugen wrote:

Could you elaborate a bit about the 'make decisions for the mapping' ? Your system (described below) sounds like it has to make sure the entity model stays close to the relational model, otherwise you'll run into situations where you have to make decisions, e.g. rename a navigator which has the same name as an inherited navigator.

We have an old database schema, with many installations, with customization. So a subset is equal among everyone. Our core system uses the common tables, and the custom code generates a complete adapter model for the entire system, and uses that code. We also use LLBGen for other projects as well, so it is not all black and white. How we like to use LLBLGen is for every change in the database, we generate the entire project from scratch, and compile the DLL. We then add the new DLL's. But in between we have old sequence mappings which I have an XML file for, and modify the project. We also set naming conventions, like manytomany etc. In addition, we have a system for storing typeconverters in the DB, and generate those, and again, modifies the project before the code is generated.

The reasoning behind this, is that we actually do not need the complexity of the designer to make the dlls, and all the options in the designer are potential "policy" breakers.

Ok, this indeed sounds like you don't want to break it up to get it working in some other form, as that will likely take more work than one might think.

I don't follow what you mean, sorry, as there's no cli refresher in the sdk at the moment. Or do you mean: we refresh in v2.6, then convert to v3 using the template, load that in v3 and generate code ? I wouldn't take that route in an automated system as it's not reliable in all cases, as the v2->v3 template can't make all the decisions. So it can be an upgrade to v3 results in some validation issues you have to fix in v3's designer.

LLBLGenPro_v3.0_SourceCode_20110107 contains a CLIRefresher.

No It contains a CLIGenerator The v2.6 code contains a cli refresher, the v3.0 one doesn't (I opened the zip file to check whether a forked project source was exported accidentally but this wasn't the case)

I was just thinking a way we could start using the v3 runtime libraries, was to create the v2.6 project as before, convert it, and generate code for v3, since the project behaves as we want it to.

I think that could work for a while but I wouldn't be surprised you'll run into problems with validation in one way or the other.

The designer has had an event system since a long time btw, and you can bind plugins to these designer events, e.g. after project load, after entity add, which could automate things for you inside the designer.

I know. But it does not comes close to the easy of starting a command, and 30 seconds later the dll's are finished. With no chance of doing anything out of the ordinary.

Out of the programmers here, none have ever had the need to open the designer, I bet just 1 or 2 have done, once. They are very happy with lllbgen, and the easy of use we have, and I do not want to change it.

Ok, fair enough .

You're not alone in this btw, more people have requested a CLI refresher for v3. I can understand you need the automated tool to fit in your pipeline. As 3.1 is now in beta already it's too late to make the changes for this. The main showstopper for this is in the area where new tables have to be selected in the cli refresher. This is currently done in a wizard fashion inside the designer, a cli refresher should pull all new tables/views etc. into the project like in v2.6 (or based on a setting). The rest of the logic is more or less available in easy to call methods, however the above logic isn't. In v2 we simply could copy the control logic for the unattended path to the cli refresher but v3 doesn't have this anymore, so this is currently missing. I'll bump the cli refresher workitem to the highest level so it will be selected for 3.2

Thank you very much

The cli refresher turned out to be really easy so we've added one and it will be released with v3.1. It will be added to the v3.1 beta which we'll release tomorrow (friday)

Otis wrote:

The cli refresher turned out to be really easy so we've added one and it will be released with v3.1. It will be added to the v3.1 beta which we'll release tomorrow (friday)

Perfect!

gulhaugen wrote:

Otis wrote:

The cli refresher turned out to be really easy so we've added one and it will be released with v3.1. It will be added to the v3.1 beta which we'll release tomorrow (friday)

Perfect!

It's available now in the beta archive released today.

After jumping through a few hoops, I'm almost ready to upgrade (when 3.1 is released )

I have one remaining issue: retrievalProperties.Add(CatalogElementRetrievalOption.AutoDetermineSProcType, true);

This automatically divided all the legacy stored procedures (which we are in the process of rewriting, but not all at once), into retrieval and action procedures.

I cannot seem to find the option in 3.1 beta.

I quess all it does is check if there is a result set parameter, so it I could do it manually.

So then I have two questions: 1) Is the option in 3.1? If so where? 2) If not, what is the pseudo code for this? Simply determine of the proc has a resultset, and modify accordingly?

Thank you very much for a solid product.

BTW; some naming conventions didn't behave the same in 3.1 as in 2.6. Minor differences: Direct conversion from old naming conventions

  userPreferences.NavigatorMappedOntoManyToManyPattern = "{$EndEntityName}CollectionVia{$IntermediateEntityName$S}_{$StartEntityFieldNames}";
            userPreferences.NavigatorMappedOntoOneManyToOnePattern = "{$EndEntityName$S}_{$StartEntityFieldNames}";
            userPreferences.NavigatorMappedOntoOneToManyPattern = "{$EndEntityName$P}_{$StartEntityFieldNames}";    

needed to be:

 userPreferences.NavigatorMappedOntoManyToManyPattern = "{$EndEntityName}CollectionVia{$IntermediateEntityName$S}{$StartEntityFieldNames}";
            userPreferences.NavigatorMappedOntoOneManyToOnePattern = "{$EndEntityName$S}{$StartEntityFieldNames}";
            userPreferences.NavigatorMappedOntoOneToManyPattern = "{$EndEntityName}{$StartEntityFieldNames}";   

to produce the identical names.

gulhaugen wrote:

After jumping through a few hoops, I'm almost ready to upgrade (when 3.1 is released )

I have one remaining issue: retrievalProperties.Add(CatalogElementRetrievalOption.AutoDetermineSProcType, true);

This automatically divided all the legacy stored procedures (which we are in the process of rewriting, but not all at once), into retrieval and action procedures.

I cannot seem to find the option in 3.1 beta.

The code generator now figures it out, so you can just add the calls. If the proc has a resultset defined (new in v3) or a number of resultsets defined (like in v2.x) it's a retrieval proc, otherwise it's an action proc.

I quess all it does is check if there is a result set parameter, so it I could do it manually.

So then I have two questions: 1) Is the option in 3.1? If so where? 2) If not, what is the pseudo code for this? Simply determine of the proc has a resultset, and modify accordingly?

Not needed, just add the proc. In the sourcecode, there's a bit of code to post process a proc, around line 250 in Engine.cs. When you set the flag to post-process the proc, the driver will try to obtain the layout of the resultsets of the proc.

BTW; some naming conventions didn't behave the same in 3.1 as in 2.6. Minor differences: Direct conversion from old naming conventions

  userPreferences.NavigatorMappedOntoManyToManyPattern = "{$EndEntityName}CollectionVia{$IntermediateEntityName$S}_{$StartEntityFieldNames}";
            userPreferences.NavigatorMappedOntoOneManyToOnePattern = "{$EndEntityName$S}_{$StartEntityFieldNames}";
            userPreferences.NavigatorMappedOntoOneToManyPattern = "{$EndEntityName$P}_{$StartEntityFieldNames}";    

needed to be:

 userPreferences.NavigatorMappedOntoManyToManyPattern = "{$EndEntityName}CollectionVia{$IntermediateEntityName$S}{$StartEntityFieldNames}";
            userPreferences.NavigatorMappedOntoOneManyToOnePattern = "{$EndEntityName$S}{$StartEntityFieldNames}";
            userPreferences.NavigatorMappedOntoOneToManyPattern = "{$EndEntityName}{$StartEntityFieldNames}";   

to produce the identical names.

In v2, pluralization / singularization wasn't enabled by default, in v3 it is. I thin that's what the differences caused.