Where can I opt-in to do some alpha-testing on LL 3.0 with all this spare time in December?

Any details on features to be published on the roadmap?

Thanks!

-Wiebe

wtijsma wrote:

Where can I opt-in to do some alpha-testing on LL 3.0 with all this spare time in December?

Any details on features to be published on the roadmap?

Thanks!

-Wiebe

We will have an opt-in beta period, where we'll select people who want to be in the beta, but that period isn't yet near, I'm afraid . It's hard to say when the period will start, but not before may 2009 I think.

Otis wrote:

We will have an opt-in beta period, where we'll select people who want to be in the beta, but that period isn't yet near, I'm afraid . It's hard to say when the period will start, but not before may 2009 I think.

That's too bad, but still looking forward to it

Wiebe

So, what all is planned / designed for v3.0? I know you have talked about different things for the future version, but I figure you are in the planning/design phase for v3.0 and wondering what the scope will be for the new version?

Wade wrote:

So, what all is planned / designed for v3.0? I know you have talked about different things for the future version, but I figure you are in the planning/design phase for v3.0 and wondering what the scope will be for the new version?

If we were still in the planning phase it would never get done hehe . It's already in development for 6 months. The designer is build from the ground up (re-using code from v2 where applicable) in .net 3.5 (still winforms) and based on our algorithm library (which will be shipped with v3) and graphs, undo/redo everywhere.

It will have model-first (new) and the good old reverse engineering of v2. You'll be able to create mappings to multiple database types in a single project, select which elements of the meta-data to retrieve (at table level), group elements into groups, use value types as field types (which can contain fields and other value types), maintain the database schema by changing mappings / elements (so changing mappings, adding new fields etc. will create change scripts for the database), projects are now stored in an XML file, you can convert mappings from db type A to dbtype B etc. so external converters are no longer needed. Templates can be edited inside the designer and it will sport a new typed list editor and a lot of other neat things I won't talk about at the moment

The final version will support our own framework (which will be updated with new features like value types), nhibernate 2.x, entity framework and linq to sql. We expect a beta around mid-2009 and have high hopes this will be the one true o/r designer one will ever need

Wow, that sounds pretty impressive. Can't wait to use it...

Regards, Diederik

Wow, can't wait!

WOW!

Oh shit! Is just march and such a long time until mid-2009.

Being it is only 3 months until mid 2009 and that development has been underway for over 9 months..................

Otis, I think it is time to update the troops with more concrete plans on what is coming and when?

We are all excited to see your work!

It will take several months before we'll present a solid build to beta-testers (who we haven't selected yet), as several essential parts (like... the code generator ) haven't been added to the new designer yet (as in: the subsystem isn't present yet).

This post: http://www.llblgen.com/TinyForum/GotoMessage.aspx?MessageID=86018&ThreadID=15441

contains a screenshot. More (better looking screenshots of models etc.) will be released in the coming months )

So, it is the first of June. How is it going? Any new updates?

Wade wrote:

So, it is the first of June. How is it going? Any new updates?

It's key that v3 is solid, has all the features necessary to stay ahead and has the ability to provide the platform for future versions. We're not there yet. It will be this year, but not soon. I'm sorry we can't give you any bits yet, but that's life I guess. I know it takes long, and it always takes longer than anticipated, and people want everything a.s.a.p., but I can assure you, we too want to finish this and get it into the hands of our community. The thing is that we're not done yet, so we can't give out bits.

We do know that one can add features forever but we've proven in the past with previous versions that we also know how to ship software, so please have confidence in us, it will be OK, and very much worth the wait.

It is always better to take your time and do it right instead of rushing half-half-baked products out.

Surely they could give us some hints and teasers?

WayneBrantley wrote:

Surely they could give us some hints and teasers?

http://weblogs.asp.net/fbouma/archive/2009/03/20/the-undo-redo-paradox.aspx http://weblogs.asp.net/fbouma/archive/2009/05/04/the-desperate-quest-for-doing-it-right.aspx

some tiny looks behind the curtains . The designer can now do things like: - multi-database type projects (1 set of entities, meta data from multiple databases like oracle, db2, sqlserver etc.) - model first (so create entities, relationships inheritance etc. first, then create meta-data from that) using clever editors. - manual mapping of entities, typed views and stored procs onto targets in every detail possible. - manually create fields in tables and sequences in targets - it has rewritten drivers, so they now use linq to objects/datasets, dbprovider factory and are no longer relying on specific ado.net provider dll versions - meta-data retrieval from databases with full freedom, so you can select which synonyms, tables, views and procs you want to retrieve meta-data for - stored proc resultset determination - reverse engineering from meta-data - value types (nesting is supported), so you can define a type 'Address' for example with fields City, Street, Country, Houseno and define entity fields of that type (or value type fields if you want to). - grouping of entities (1 level deep) - mapping typedviews on views, tables (for read only access) and stored proc resultsets - completely new typed list editor with visual relationship representation - model validation and meta-data adjustment with clever error/warning reporting ala vs.net but then better: an error is accompanied with a set of corrections with links, which you can click which for example open the editor of the element to correct or do the correction for you when clicked. - multi-select project / catalog explorer - you can mark elements as removed in the catalog explorer which are exported as DDL SQL drop statements. - foreign key fields are now separated - relationships are now editable, you can change relation types after creation - project files are now in XML and save/load is very very fast compared to v2.x - and many many many other things

As with v2.x, all editing work is done live on the model, not on a file, so everything relates to eachother and is kept in sync and if you make an error (e.g. map a string typed field onto a numeric target field) you're warned with a small error icon that something is wrong. If you create a relationship between A and B, fk fields are created automatically if the the pk side has a pk or added when the pk is added, and removed if the pk is removed. All undoable / redoable of course

Most of the work has been spend on writing a solid foundation framework (in Algorithmia and on top of that) so adding features to the designer was simpler and the code would be more extensible. For example, the model is now a graph and everything is undo-redo aware without the developer having to worry about creating commands, it's transparent. Reporting messages/errors is centrally controlled etc. This took a lot of work but it was well worth it. Also as model first was a prominent feature, we couldn't re-use a lot of code of v2.x's designer when it came to entity model classes. So instead we port 'intent' and rewrite the code in .net 3.5 C#, which also gives more compact code due to linq to objects and the new general object model.

What's ahead of us is still a lot of work but we're far beyond halfway the project which is a good thing, so we can work towards a known goal, the list of things to include isn't endless anymore. I'm personally very happy with how things progress and how well the work on the general foundation has panned out. No pretty screenshots to show yet, I'll keep those under wraps when the search -> results -> model feature is added. . Tomorrow is june 6th, a full year after v2.6 was released, and of course we would have liked to have v3.0 to be done by now, but as this is stuff which needs research to get done right, it's always a gamble if ideas up front pan out as expected or suck and should be thrown out. As with 1.0.2003.1, the first version of llblgen pro all those years ago, we now too had to throw out our initial editor idea which costed us at least 2 months of work, but at the same time it's nice it happened early and we know from the past to take painful decisions early. Luckily we found a different way to edit entities which IMHO is also easier to use than our text-based DSL we had earlier (as now full model-editing is possible, everything is kept in sync and is maintained from every angle).

At launch we'll support LLBLGen Pro RT 3.0, Entity framework 1.0/4.0, NHibernate 2.x and Linq to Sql, with many more frameworks planned, also Java frameworks like Hibernate.

Hi Frans,

In regards to the new : xml project file

I was wondering you've done any testing on merging the the XML project files, for instance if you were to branch a project and make multiple changes to the model/db structure and then merge the changes back. Somewhat related, is the diff between two different point in time versions of the file useful as a substitute for something like red-gate sql compare to generate change scripts.

I'd wait for version 3.0 to find out since I'm sure you're busy but I've just recently had some fun with these exact issues so thought I'd see if there was any new information.

Tim

tmpreston wrote:

Hi Frans,

In regards to the new : xml project file

I was wondering you've done any testing on merging the the XML project files, for instance if you were to branch a project and make multiple changes to the model/db structure and then merge the changes back. Somewhat related, is the diff between two different point in time versions of the file useful as a substitute for something like red-gate sql compare to generate change scripts.

It's designed to be mergable with sourcecontrol systems and diff systems, however as things are related to eachother, it might be that you have to manually help the merge process a bit. The format is designed to be human readable, so no SOAP like XML, but normal XML like this:

<EntityDefinition Name="Employee" GroupName="">
<Fields>
  <Field Name="Address" Type="string" IsOptional="true" MaxLength="60" />
  <Field Name="BirthDate" Type="datetime" IsOptional="true" />
  <Field Name="City" Type="string" IsOptional="true" MaxLength="15" />
  <Field Name="Country" Type="string" IsOptional="true" MaxLength="15" />
  <Field Name="EmployeeId" Type="int" IsReadOnly="true" Precision="10" IsPrimaryKey="true" />
  <Field Name="Extension" Type="string" IsOptional="true" MaxLength="4" />
  <Field Name="FirstName" Type="string" MaxLength="10" />
  <Field Name="HireDate" Type="datetime" IsOptional="true" />
  <Field Name="HomePhone" Type="string" IsOptional="true" MaxLength="24" />
  <Field Name="LastName" Type="string" MaxLength="20" />
  <Field Name="Notes" Type="string" IsOptional="true" MaxLength="1073741823" />
  <Field Name="Photo" Type="byte[]" IsOptional="true" MaxLength="2147483647" />
  <Field Name="PhotoPath" Type="string" IsOptional="true" MaxLength="255" />
  <Field Name="PostalCode" Type="string" IsOptional="true" MaxLength="10" />
  <Field Name="Region" Type="string" IsOptional="true" MaxLength="15" />
  <Field Name="Title" Type="string" IsOptional="true" MaxLength="30" />
  <Field Name="TitleOfCourtesy" Type="string" IsOptional="true" MaxLength="25" />
</Fields>
<ForeignKeyFields>
  <ForeignKeyField Name="RegionId" MappedField=":Region:RegionId" RelationshipName="Employee.Region_-Region.Employees" ViaStartNavigator="true" IsOptional="true" />
  <ForeignKeyField Name="ReportsTo" MappedField=":Employee:EmployeeId" RelationshipName="Employee.Employee-Employee.Employees" ViaStartNavigator="true" IsOptional="true" />
</ForeignKeyFields>
</EntityDefinition>

so it's rather easy to merge these files. Everything is referred to by name (which are unique) and sorted in such a way that things are always at the same location in the file, so when you for example change a field's length, you'll see the different length value as the only diff between two files.

As files will become bigger and bigger, it might be more time consuming to merge them together, but it still should be rather easy: it's similar to merging two code bases together which refer to eachothers elements: things might need manual correction. Though I expect people to work on different parts of the model, not the same elements (as that would suggest bad management: if two people edit the same element, one person should give the other person the requirements for change), so merging should be rather straightforward.

There's not really any other way to do this. Saving it in a textual DSL form also gives the same problems: entity X is mapped onto table T and either T or X changes in the two versions of the source project: merging them together still requires manual work.

As everything is humanly readable (and documented, so with the .xsd it's even possible to write the project from scratch in an xml editor) it's not that hard to fix load errors, if they might occur after a merge.

It might be necessary to use xml merge tools (which exist! ) instead of plain-text diff tools, as it's xml, not plain text, for huge merge actions though. But it all beats the binary blob we use now