Custom datasources vs DMI

[bbruyn]

Mostly, I get what I need from documentation, examples, or this forum, but there are of course gray areas where I could use some guidance from time to time. In particular, there is obviously some overlap in what you _could_ do with custom (SQL) datasources and DMI, so I was wondering:

Is there a general-purpose philosophy at Isomorphic regarding when you should prefer one or the other?

[Isomorphic]

As a starting point, there's what the QuickStart Guide says: if you have behaviors that apply to all of your SQLDataSources, then pervasively adding DMI declarations is going to become very redundant, so that's a clear use case for serverConstructor (subclassing SQLDataSource).

Similarly, if you implement a feature that can be turned on by custom markup in .ds.xml files, that's another clear one for serverConstructor.

From there, it depends a lot more on the application, and your individual taste on code organization. Some considerations:

1. You can have a single DMI class that gathers together DMI logic from several closely related DataSources. Sometimes having this single DMI class provides nicer code layout than having several SQLDataSource subclasses with closely related code, where yet another class may be introduced to hold common helper methods.

2. A DMI declaration on a specific operationType very clearly indicates that that operation doesn't have standard behavior, so you know you have to read the DMI logic to understand what's special about the operation. A serverConstructor declaration means you always have to read Java to understand which specific operations have been customized.

3. Certain styles of using Aspect-oriented programming (generally via Spring) to inject logic before or after a method call work better with DMI-based code organization or with serverConstructor-based code organization.

So, there are no hard and fast rules, and there's a lot of room for individual taste. But as a general guideline, use serverConstructor to avoid situations where DMI declarations become repetitive.

If this didn't answer your question or you want advice on a specific scenario, please follow up with more details.

[jpappalardo]

What I found as a short coming of custom datasources is join relationships. You cannot have two Custom DataSource instances that declare a relationship on each other. In order for the relationships to work, they must be of the same DataSource.

In our project we found it was necessary to use both implementations. A custom DataSource for providing realtime client updates, and making notifications to server side code about db changes. This prevented having to rewrite the same code in each DMI, while allowing join relationships to be retained. While the DMI provided the ability for implementing custom logic for a specific entity.

If we had it to do all over again, we would not have extended JPA2DataSource, and instead would have used the SQLDataSource.

[Isomorphic]

??

There's no limitation like you describe. What happens is that if two DataSources are of the same serverType (not className), then they can do an actual SQL join, otherwise, they will need to do a (very inefficient) in-memory join. This is covered under the includeFrom docs.

Going further than this would require "magic". There no way, for example, a SQLDataSource could join to a JPADataSource, because JPA just does not expose the required information at all - JPA doesn't even have a way to find out the database settings in use.

What you can do, and what people sometimes do while migrating from JPADataSource to SQLDataSource, is use SQLDataSource to directly access the same SQL tables that they otherwise access through JPA. Then SQL Templating lets you use whatever SQL you want.

[bbruyn]

As a starting point, there's what the QuickStart Guide says: if you have behaviors that apply to all of your SQLDataSources, then pervasively adding DMI declarations is going to become very redundant, so that's a clear use case for serverConstructor (subclassing SQLDataSource).

Similarly, if you implement a feature that can be turned on by custom markup in .ds.xml files, that's another clear one for serverConstructor.

Yeah, those cases are pretty clear. By the way, the Quick Start also reads,

You can create a DataSource that calls existing business logic by simply using DMI to declare what Java method to call for each operation. This is a good approach if you have only a few DataSources, or while you are still learning the basics

I don't think you meant it the way it sounds, but that 2nd sentence reads like a recommendation to prefer custom datasources to DMI for calling business logic on larger / more advanced projects.

As documentation and samples both point out, you could for example write some custom validation in either a datasource implementation or in a DMI (or in a validator, as far as that goes). It's pretty much the same thing. If you didn't care about some of the DMI-specific features (e.g., automatic population of JavaBean method parameters), you could use custom datasources entirely and never care that there was any DMI feature. Conversely, you could do everything in DMIs if you had no common processing (auditing or whatever).

That's the kind of gray area I was referring to. Like you say, a matter of preference I suppose.

[Isomorphic]

Yeah, those cases are pretty clear. By the way, the Quick Start also reads,

You can create a DataSource that calls existing business logic by simply using DMI to declare what Java method to call for each operation. This is a good approach if you have only a few DataSources, or while you are still learning the basics

I don't think you meant it the way it sounds, but that 2nd sentence reads like a recommendation to prefer custom datasources to DMI for calling business logic on larger / more advanced projects.

.. which is actually accurate. The larger the project the more likely there is reusable code that could be factored into DataSource subclasses. In a very small project, it's less likely there's logic like this, and most people find DMI simpler to understand.

But it is true that we did *not* mean to imply that DMI should not be used at all for a larger project. It's not clear that there's a wording change here that wouldn't turn into a mini-opus on the subject of DMI vs subclass tradeoffs :)

If you didn't care about some of the DMI-specific features (e.g., automatic population of JavaBean method parameters), you could use custom datasources entirely and never care that there was any DMI feature.

Just a note that DMI's auto-population feature can be replicated with a single method call - DataSource.setProperties().