in dsl section dao IntIdTable is proposed

[victororlyk]

in dsl section dao IntIdTable is proposed

[bog-walk]

I agree that it could be confusing for a user to see examples in the DSL section that use IntIdTable and require what appears to be a DAO import, especially if the user has zero intention of including a dependency on the exposed-dao module.

However, all IdTable subclasses are actually part of the exposed-core module, most likely to be a bridge so that they and EntityID can be referenced by core classes and functions. So a user who plans to never use DAO would still have immediate access to these tables through the exposed-core dependency and it would be up to the user to choose to never use them.

So, yes, while there should be less emphasis on using IntIdTable to reduce boilerplate, the inclusion and availability of these tables in the core module and DSL can't be fully ignored.

At the moment, you won't see much change in the Wiki, but that's because we are actively working towards improving and publishing all Wiki documentation to an Exposed website. All samples will also be re-evaluated/re-written, so this issue with where to draw the line between DAO and DSL will be properly addressed.

If you're interested in more updates about documentation and Exposed in general, here is a link to the most recent official blog post regarding our plans moving forward.