Denodo Platform 9 Certified Developer Professional common mistakes
Denodo Platform 9 Certified Developer Professional · Understand the traps and how to avoid them.
Treating a base view as if it were a live pass-through to the source, and expecting that filtering a base view in a query automatically pushes all predicates to the underlying database.
Candidates assume Virtual DataPort always delegates execution to the source. In reality the optimizer decides what to push down based on source capabilities, wrapper type, and the query shape; some expressions are evaluated in the VDP engine. Confusion between base view definition and execution plan leads to wrong answers about performance and about where a filter actually runs.
What to do instead
Learn to read the execution plan (contextual menu on the view / 'Execution plan' trace) and identify which node is delegated versus executed locally. Study how source capabilities and the 'Delegate' / pushdown settings affect the plan, and how to force or forbid delegation when a source cannot handle an expression.
Choosing the wrong join type or join order when building derived views, and assuming Denodo will always rearrange joins to the optimal order regardless of the view's structure.
The optimizer performs join reordering and cost-based decisions, but there are limits: outer joins constrain reordering, and views with certain constructs (unions, aggregations, subqueries) restrict what can be pushed down. Candidates who assume 'the engine will fix it' pick incorrect answers about which plan is generated.
What to do instead
Practice reading plans for inner versus outer joins and note when reordering is blocked. Learn to use the 'Join' and 'Union' dialog options deliberately, and know that rewriting a view (e.g., pushing a filter before a union branch) can change the plan. Verify assumptions against the execution plan rather than intuition.
Assuming that creating an association (or a tag, or a description) in the model changes query behavior or enforces referential integrity.
Associations in Denodo are metadata used for documentation, for suggesting joins in the GUI, and for exposing relationships in the catalog/API; they do not create constraints or automatically join views. Candidates conflate logical modeling with physical enforcement.
What to do instead
Separate the two concepts explicitly: associations describe relationships for governance and for join suggestion; actual joins are defined in derived views. Be able to state what an association does and does not do, and where it appears (Design Studio model, catalog metadata, OData navigation if configured).
Confusing authentication with authorization when configuring access to a view, e.g., expecting that adding a user to an LDAP directory grants them access to data, or that a role assignment authenticates the user.
Denodo separates the identity provider (LDAP, Kerberos, SAML, database, etc.) from the authorization model (roles, privileges on elements, row-level and column-level policies). Questions often describe a symptom and ask which layer is misconfigured; candidates pick the wrong layer.
What to do instead
Build a mental checklist: who is the user (authentication) versus what may they see (privileges, roles, policies). Learn the privilege hierarchy on databases, views, and columns, and how role inheritance works. Practice diagnosing 'user can log in but sees no rows' as an authorization/policy problem, not an authentication one.
Applying masking or row-level security at the wrong layer, for example masking in the derived view's SELECT list instead of using a policy, or expecting masking to apply to users with administrative privileges.
Denodo offers several mechanisms (masking views, column-level masking policies, row filters) and they differ in where they are enforced and who is exempt. Candidates memorize one mechanism and apply it to every scenario.
What to do instead
Learn each mechanism's scope and precedence: masking views versus policy-based masking, and how row filters interact with role assignments. Note that administrators typically bypass or are excluded from certain policies, and design tests with a non-admin user to confirm behavior.
Publishing a REST or OData service and assuming the resulting API automatically exposes all columns, supports all filter operators, or returns the same shape as the underlying view.
Published services are governed by the view's schema, by the service configuration, and by the protocol's own semantics (OData query options, REST pagination, GraphQL schema generation). Candidates expect a 1:1 mapping and misjudge what a client will actually receive.
What to do instead
For each protocol, know what is generated and what is configurable: OData entity sets and navigation properties from associations, REST resource paths and output formats, GraphQL type generation and resolvers. Test the published service with a real client and inspect the metadata document or schema.
Enabling caching and expecting every subsequent query to be served from cache, without accounting for cache invalidation, cache mode, or the fact that a query must match the cached query exactly.
Denodo's cache has modes (full, partial, and others) and invalidation rules tied to source updates or schedules. Candidates treat cache as a blanket performance switch and misanswer questions about when a cached result is reused.
What to do instead
Study cache modes and invalidation options, and the conditions under which a query hits or misses the cache (including query text and parameter matching). Pair this with other acceleration techniques (summary views, MPP acceleration, materialized views) and know when each is appropriate.
Designing a Scheduler job that reloads a full table every run and calling it an incremental load, or assuming Scheduler detects changes in the source automatically.
Scheduler moves data according to the job's configuration; incremental behavior requires an explicit strategy such as a timestamp/sequence field, a cache invalidation pattern, or a change-data-capture source. Without that, the job simply re-extracts. Candidates who have not configured an incremental job confuse scheduling with delta detection.
What to do instead
Learn the concrete incremental patterns: filtering on a last-modified or increasing key, storing the high-water mark, and handling deletes. Know how to define the job's source query, the target, and the parameters that carry state between runs, and how to test a second run to confirm only new rows move.
Assuming that exporting a solution with Solution Manager captures every runtime artifact, or that deploying a revision to a new environment requires no environment-specific reconfiguration.
Solution exports capture the elements selected and their metadata, but environment-specific values (data source connection strings, credentials, server URLs) must be handled separately, and revisions are versioned snapshots with their own deployment flow. Candidates skip the environment-specific step and expect a clean deployment.
What to do instead
Learn the lifecycle: develop in Design Studio, create a revision, export, then deploy via Solution Manager, and know where environment-specific parameters are substituted. Practice identifying which elements must be included in the export and which settings are environment-bound.
Misjudging the role of the different Denodo servers and components, e.g., assuming the Virtual DataPort server stores the scheduler's job definitions or that Design Studio is required at runtime for queries to work.
The platform separates the VDP server (query execution and views), the Scheduler server (jobs and data movement), the catalog/Data Catalog, and the client tools (Design Studio, administration tools). Candidates blur these boundaries and answer architecture questions with the wrong component.
What to do instead
Draw the component map and label each responsibility: which server hosts what, which port/protocol each uses, and what is needed at runtime versus design time. Then check installation and administration topics (server startup, licensing, backups, monitoring) against that map so each fact is anchored to a component.