Debugging Magik database queries from Emacs

Database work in GE Smallworld often becomes difficult at the point where Magik code, GIS data, and a long-running application session meet. A query may return an empty collection, select the wrong records, or appear to stop inside a method that looks perfectly reasonable in the source file.

Emacs can make this investigation more controlled. With suitable Magik support, you can move quickly between method definitions, fold away unrelated code, inspect objects, and use the Smallworld development environment without losing the context of the failing query.

That workflow is valuable for teams across Australia, where Smallworld systems support utilities, transport, local government, telecommunications, and spatial asset management. A developer in Melbourne might be tracing council infrastructure, while a Perth team investigates network assets or a Brisbane group checks data affected by a major project. The principles remain the same: isolate the query, inspect its inputs, and verify the returned objects.

Establish a repeatable debugging session

Begin by reproducing the query in a known application state. Record the current product, database, user role, and session configuration before changing code. A result that appears to be a query fault may instead come from a different open world, transaction state, dataset version, or access privilege.

Keep the smallest useful Magik expression close at hand in an Emacs buffer. Rather than rerunning an entire workflow, extract the method call or query construction that produces the unexpected result. This makes it easier to compare successive changes and prevents unrelated user-interface actions from hiding the real cause.

A reliable session also includes a clear way to return to the same test data. Australian projects frequently work across development, test, and production environments managed by different offices, including teams split between Sydney and Adelaide. Naming the environment in a comment or temporary test method can prevent hours of investigation against the wrong database.

Read the query before stepping through it

Magik queries commonly combine selection criteria, collections, methods, and object relationships. Read each stage separately before placing a breakpoint. Identify the source collection, the filtering expression, the expected object type, and the operation that consumes the result.

For example, a query may be logically correct but receive a collection containing network features from a different class. A property comparison can then return no matches without raising an obvious error. In Emacs, code folding helps hide surrounding application logic while you focus on the query pipeline and its immediate arguments.

Method navigation is especially useful when a query calls a project-specific wrapper. Jump into the wrapper rather than assuming it behaves like a standard database operation. Check whether it converts values, applies an implicit spatial restriction, limits records, or handles a null attribute before the final selection occurs.

Use breakpoints at data boundaries

Place the first breakpoint before the query is built and the second after each meaningful transformation. This creates observable boundaries: input values, source collection, filtered collection, selected objects, and final presentation or update logic.

A breakpoint at the start of a method confirms that execution reaches the expected code. A later breakpoint confirms whether the query returns normally. If execution never reaches the second point, step into the operation that sits between them and inspect its arguments rather than immediately changing the database expression.

Conditional breakpoints are useful when a large collection contains thousands of records. Stop when an object has a particular identifier, class, or attribute value. This is often faster than repeatedly stepping through every record, especially when working with large utility networks around Sydney or extensive mining-related datasets in Western Australia.

Inspect objects and collections in context

The debugger is most valuable when it shows the actual runtime object rather than only the source expression. Inspect the collection class, its size, representative members, and the values used by the predicate. A collection that prints plausibly may still contain a different object type or a mixture of objects with different attribute availability.

Check whether a value is unset, false, empty, or represented by a special Magik value. These states can affect equality tests and conditional branches. Also inspect the type of values returned from forms, configuration files, or user input. A character string that looks like a number may not compare as expected with a numeric database attribute.

Object inspection should include the relationship between objects. If the query selects a child feature through a parent record, verify that the parent reference is valid and belongs to the current database. Emacs tools for viewing slots or jumping to accessor methods reduce the time spent searching through large class definitions.

Separate database faults from Magik faults

A failed result does not automatically indicate corrupted or missing database data. First test whether a known object can be retrieved by a stable identifier. Then test the same condition in smaller stages. This distinguishes an unavailable record from a malformed predicate or an incorrect relationship.

When the database contains the expected feature, compare the query’s value with the value stored on the object. Pay attention to case, whitespace, units, coordinate systems, and local conventions in imported data. A road name, suburb, or asset code may differ between an authoritative source and an operational layer even when both appear identical on screen.

The reverse problem also occurs: the query may be sound, but the current world or transaction does not expose the record. Check database connections, edit permissions, visibility rules, and any application-specific filters. For local councils preparing works programmes around Canberra or the Gold Coast, a permissions or versioning difference can look like a missing feature during a busy release period.

Make query failures visible in Emacs

Temporary diagnostic output should identify the stage that failed and the values involved. Print collection counts, object identifiers, class names, and key attribute values rather than dumping every object. Focused output remains readable in the Emacs Messages buffer or the Smallworld command window.

A small diagnostic helper can make repeated checks consistent. For instance, a method can report whether a collection is unset, empty, or populated, then display the class of its first member. Keep such helpers separate from production logic and remove or disable them after the fault is understood.

Emacs makes this cycle efficient. Send a revised definition to the running Magik environment, rerun the narrow test, and return to the same source location. Code folding keeps logging statements from overwhelming the method, while search and cross-reference tools reveal other callers that may depend on the query’s current behaviour.

Trace performance as well as correctness

A query that returns the right records can still be unsuitable for production. Measure how long it takes, how many objects it examines, and whether it repeatedly performs the same lookup inside a loop. A debugger can reveal the point where execution slows, while collection inspection shows whether an unexpectedly broad selection is responsible.

Start with the narrowest filter that can answer the business question. Apply selective conditions early, avoid recalculating stable values, and confirm that a method is using the intended index or access path where the application provides one. Test with realistic data volumes rather than a small developer dataset.

Performance matters during Australian operational periods such as end-of-financial-year reporting, storm response, and planned infrastructure releases. A query that feels acceptable in a quiet Melbourne test environment may become a bottleneck when a utility team processes a statewide dataset or several users access the same system concurrently.

Turn the investigation into reusable practice

Record the failing expression, sample identifiers, environment details, observed collection sizes, and the final cause. This gives the next developer a useful diagnostic trail instead of a vague note that “the query returned nothing”. Include the relevant method path and any assumptions about database state.

Reusable Emacs commands can make common checks nearly automatic. A command might send the current method to the Magik listener, place the cursor on a referenced method, or open a diagnostic buffer beside the source. Keep the workflow close to the code so that investigation does not depend on memorised listener commands.

Teams that need help adapting this workflow to an existing Magik and Emacs setup can use Magik Emacs support to discuss extensions, debugging practices, and consulting requirements. This is particularly useful when a project has a mixture of legacy Magik code, custom database wrappers, and newer developer tooling.

A disciplined query investigation should leave behind more than a single fix. Add a focused regression test, preserve a representative data case, and document the distinction between an empty result and an invalid query. Explore the Magik Emacs tools, refine your debugging commands, and make database diagnosis a routine part of development rather than an emergency exercise.