Menu

Improvements to the DA LINQ workflow in Data Abstract 7

One of the many improvements in the all-new Data Abstract 7 is that we completely revamped the user experience for creating and updating the strongly typed code files for DA LINQ in DA/.NET.

If you create a DA project from one of the templates and use our wizard, your project will already start out with a TableDefinitions source file that reflects all the tables you selected in the wizard. But sooner or later, your schema will change and evolve, and then code will need to be updated. Also, you might have an existing non-DA project that you want to add DA client functionality to, and in this case you will want to create a fresh TableDefinitions file.

Let’s have a look at this.

In the simplest case, which already worked fairly similar in previous versions, your solution contains a custom DA server and with it one or more actual .daSchema files. In this case, you can simply right-click the .daschema and choose “Create DA LINQ Table Definitions” from the context menu:

This will launch our new wizard for this process, in this case with only a single page:

This screen allows you to specify three things:

The file to generate or update. If there’s already one (or more) existing table definition source files in your solution, you can select a file (from any of the projects) here; you can also specify a new file to be created.

The namespace to be used for the generated or updated file.

The list of tables to generate classes for.

Another new and improved thing here is that if you are updating an existing file, the wizard will automatically persist the existing namespace, as well as any tables you previously decided to not generate code for by unchecking them (new tables that have been added to the schema since you last generated the code will be checked by default).

When you click Finish, the code file with your DA LINQ classes will be created or updated and opened in the IDE.

Remote Schema Files

So far so good. But what happens for client-only projects, where you don’t have the server or a .daSchema file in your solution?

We have introduced a new file type for this, called .daRemoteSchema. The project wizard (or the DA LINQ wizard) will automatically add these files to your client project as needed, and you can think of them as a kind of “link” to the schema on the DA server that is running elsewhere (or locally).

Just as with a .daSchema, you can right-click these .daRemoteSchema files and find the “Create DA LINQ Table Definitions” option in the context menu:

When invoked, it opens the same wizard you have seen above, but with an additional first step:

The wizard gathers the location and options for the remote server from your .daRemoteSchema file, lets you adjust them if necessary, and optionally provide the login for the server, if needed (you can opt to store the login in a .daRemoteSchema.user file for future reference, so you don’t need to re-enter it every time you update the table definitions — the idea being that while the .daRemoteSchema file is part of your project, you would exclude the .daRemoteSchema.user file from version control to keep your login safe).

When you click “Next”, the wizard goes out to the network and fetches the schema from your server (which should be running and accessible), and then continues on to the same page you’ve already seen above.

Relativity Client Files

In a similar fashion, we are also introducing a new .relativityClient file type to provide a reference to a Relativity Server that your application might be talking to.

Once again, the file will be automatically added by the new project wizard when you create your application, and you can simply right-click it to invoke the now-familiar “Create DA LINQ Table Definitions” option:

As above, selecting this option shows the DA LINQ wizard, this time with a page tailored for the Relativity Server connection:

You can verify or update you server address (the wizard and .relativityClient files also support ZeroConf-discovered servers), and select a domain and schema to work with. All these settings will be persisted in the .relativityClient file for future reference.

When you click next, you once again get the same wizard page shown above.

Adding New Client Connectivity

In addition to invoking the DA LINQ wizard from the three file types seen here, you can also trigger it from a global menu item (“RemObjects SDK|Create DA LINQ Table Definitions”) or a button in the Solution Explorer toolbar.

When invoked in this fashion, it will give you three choices:

Proceed with an existing .daSchema, .daRemoteSchema or .relatvityClient file, if one exists in your solution (this will take the exact same path as if invoked straight from the file as seen above).

Freshly connect to an existing remote DA server.

Connect to an existing Relativity Server domain.

The last two options will ask for the connection parameters for the server you want to connect to (on a screen similar to the ones seen above), and then automatically add a new .daRemoteSchema or .relativityClient file to your project, alongside the generated code file.

Other Benefits of .daRemoteSchema and .relativityClient Files

In addition to giving you quick access to the DA LINQ wizard, these new file types also have another benefit: by double-clicking the file (in Solution Explorer or in Windows Explorer), you can launch straight into the new Schema Modeler 7 (which i’ll talk more about in future bog posts).

For .daRemoteSchemas, DASM7 will download the schema from the server and present it to you read-only, giving you a quick and easy way to browse and explore the schema your application is working against.

Much more importantly, for .relativityClient files, DASM7 will connect to the Relativity Server and — much like you might already know from our Schema Modeler for Mac — remotely design and edit the schema(s) stored in your Relativity Server domain (this will also be the topic of another upcoming blog post).

Summary

So this is a first peak at some of the workflow improvements that Data Abstract 7 for .NET is bringing to working with DA LINQ. We hope you like them and stay tuned for more!