Hi,

We are considering to use LLBlGen for our DAL. In our development process, we will be multiple users modifying the schema and our DataAccessObjects in parallel. This can be for different reasons : bugfixing a production version while other work on the next, or simply because we work in branch in our VCS.

If we use LLBlGen in this process, the .lgp file will be enhanced in multiple branches and all these enhancements will have to be merged together in time.

If the .LGP file was in XML or other text based format, branching and merging will not be an issue (CVS, ClearCase or what ever intelligent VCS tool you might use will do it).

So, my questions : * Is it possible to store the project information in a XML or other text based format ? (currently it is binary) * Or, does LLBLGenPro offer some merging facilities ?

Thanks for your answers, Benoit

bvo wrote:

Hi,

We are considering to use LLBlGen for our DAL. In our development process, we will be multiple users modifying the schema and our DataAccessObjects in parallel. This can be for different reasons : bugfixing a production version while other work on the next, or simply because we work in branch in our VCS.

If we use LLBlGen in this process, the .lgp file will be enhanced in multiple branches and all these enhancements will have to be merged together in time.

If the .LGP file was in XML or other text based format, branching and merging will not be an issue (CVS, ClearCase or what ever intelligent VCS tool you might use will do it).

No that's a myth. Merging 'text' is easy, though merging XML isn't. That requires an XML dom, not a text merger. Especially with data which is related to eachother, as in a hierarchical object graph like the llblgen pro project, it's not solvable with a text merging tool, even if you export it as XML.

We're looking into versioning features for the object graph, though it's really a scheduling issue: as long as the .lgp file is updated by person A before person B continues with it, it's ok. The schema on the database isn't mergable as well, especially after the application is in production: you make modifications to an existing schema, for example through scripts, and then update the .lgp file to update the project with the updated schema, then generate code again and you're updated. If you have 3 or 4 different versions of a database schema, it's hard to merge that if the schema actually contains data and is in production, even though you can merge teh DDL SQL in a textmerger, that doesn't mean the actual tables are merged in the database.

So, my questions : * Is it possible to store the project information in a XML or other text based format ? (currently it is binary)

As the project contains the complete schema information, it's a lot of data. Storing just mappings into an XML file is doable, storing both the entity definitions and the table/view definitions in xml AS WELL, is a lot of data and makes loading/saving the projects too slow, which is why we switched to binary in the first place (we first had it in xml, but with 300+ entities it's too slow, when it's in XML)

• Or, does LLBLGenPro offer some merging facilities ?

Not at the moment. In future releases we've planned to offer object graph merging, which thus track changes made by different persons. This is however a complex task and therefore takes a lot of time to get it completely right and 100% bugfree.

Thanks for this very fast answer.

Otis wrote:

No that's a myth. Merging 'text' is easy, though merging XML isn't. That requires an XML dom, not a text merger. Especially with data which is related to eachother, as in a hierarchical object graph like the llblgen pro project, it's not solvable with a text merging tool, even if you export it as XML.

If you change the indentation, or do major structural changes in your XML tree, yes. But in 99% of the cases I have seen in the past 4 years, merging XML files has never been a problem.

Otis wrote:

As the project contains the complete schema information, it's a lot of data. Storing just mappings into an XML file is doable, storing both the entity definitions and the table/view definitions in xml AS WELL, is a lot of data and makes loading/saving the projects too slow, which is why we switched to binary in the first place (we first had it in xml, but with 300+ entities it's too slow, when it's in XML)

I think it first depend on the XML technology you use (DOM,SAX, ...). I have recently done some .NET parsing of 20 megs files which took only 4-5 seconds. And I do not expect a XML LLBlGen configuration to be much bigger then a few 10k.

Thanks anyway for your answer, we will see how we can adapt our needs to these restrictions, Regards, Benoit

bvo wrote:

Thanks for this very fast answer.

Otis wrote:

No that's a myth. Merging 'text' is easy, though merging XML isn't. That requires an XML dom, not a text merger. Especially with data which is related to eachother, as in a hierarchical object graph like the llblgen pro project, it's not solvable with a text merging tool, even if you export it as XML.

If you change the indentation, or do major structural changes in your XML tree, yes. But in 99% of the cases I have seen in the past 4 years, merging XML files has never been a problem.

If you say so . I have different experiences, but I agree it can be done, I though think the XML format itself has to be suitable for it as well. For example xml generated through the soap formatter is useless for merging.

Otis wrote:

As the project contains the complete schema information, it's a lot of data. Storing just mappings into an XML file is doable, storing both the entity definitions and the table/view definitions in xml AS WELL, is a lot of data and makes loading/saving the projects too slow, which is why we switched to binary in the first place (we first had it in xml, but with 300+ entities it's too slow, when it's in XML)

I think it first depend on the XML technology you use (DOM,SAX, ...). I have recently done some .NET parsing of 20 megs files which took only 4-5 seconds. And I do not expect a XML LLBlGen configuration to be much bigger then a few 10k.

Parsing is one thing, but re-creating the object graph is another. I'm not sure if the XmlSerializer can pick up our current graph, I've to do some tests again, though my experiences with the XmlSerializer are not good (we use the xmlserializer for example to read the config files for the generator and the template sets, and this is not that fast, while the data is pretty simple), so a custom xml serializer has to be written, and our object graph isn't small. But it can be a solution to the problem of versioning, you're not the first to ask for this, and because we'll add functionality for this anyway, an Xml serializer is perhaps easier to write than a full blown object versioning layer.