Browse Prior Art Database

Support for database event monitoring during application debugging in an IDE

IP.com Disclosure Number: IPCOM000245623D
Publication Date: 2016-Mar-22
Document File: 2 page(s) / 24K

Publishing Venue

The IP.com Prior Art Database

Abstract

Debugging enterprise applications, where frequent calls are made to an underlying relational database, can be complicated as the developer needs to pay attention not only to the logic flow in the code but also to the changes in the data structures within the application's database. This article proposes an integrated solution where database state changes can be tracked and debugged in a similar way to variable changes in the code.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Support for database event monitoring during application debugging in an IDE


1. Introduction

Enterprise applications very often make use of some relational database. During development of such application in an Integrated Development Environment (IDE), it is easy to debug the code flow step by step using widely available tools. However, it is more difficult to correlate what is going on in the code with what is going on in the database. It may happen that some settings which are kept within the program's database alter the execution flow in unexpected ways and the resulting unexpected behavior is difficult to debug. Popular IDEs usually offer very good support for code development (e.g. Java/Debug perspective in Eclipse) and very good support for SQL development incl. stored procedures debugging (e.g. IBM Data Studio offerings) but there is no good proposal for analyzing database behavior together

with code behavior.

This article proposes a mechanism (it could look like a view within a debugging tool)

which will allow to set breakpoints based on database state. This will allow the

developer working on application code or troubleshooting application behavior to stop the execution and see what code is currently being executed or was recently executed. Later he/she can resume the execution and continue to debug is application. The advantage of using this solution is that current most popular IDEs (per https://blog.codeanywhere.com/most-popular-ides-code-editors/ it's Eclipse, Netbeans and IntelliJ) do not have it and hence the developer cannot directly troubleshoot the database behavior within his IDE.


2. User scenario

Let's imagine a user who wants to determine what application code is updating a row in some table that his product is using. He can achieve this goal using the proposed tool in following steps:


a. Before he starts debugging, he configures the connection properties for the database used by his application - properties such as host, port, database name , user name and password - in the tool. Then the tool connects to this database and displays the list of all database objects such as tables, views, stored procedures, etc.


b. User browses this list of objects and recognizes a table which he is interested in. He selects it in order to set a breakpoint. He can specify which operations on the table should cause the breakpoint to be activated (row insertion, row deletion, row update). He can also specify additional conditions to describe the state which he

wants to capture using the breakpoint.


c. User runs his application in debug...