Leaderboard

Hi Daniel (Its_Alive) and everyone in this thread, I have been analyzing this project thoroughly, and the architectural concept behind your SQLiteLsp extension is brilliant. Having a dedicated BRX module with an embedded SQLite engine that exposes clean AutoLISP functions like (DSQL_OPEN), (DSQL_ASSOCQUERY), and (DSQL_CLOSE) is exactly how professional data-driven CAD/CAM applications should be built. However, after running a deep compatibility check for our current enterprise furniture design engine (project ZEN PRACA V2B34), we hit a classic deployment bottleneck. The original module was compiled for BricsCAD V12 around 2011. Even looking at later iterations for IntelliCAD, relying on a pre-compiled binary extension (.brx / .irx) creates a heavy production risk regarding x64 architecture alignment, modern compiler library dependencies, and strict binary compatibility with newer host CAD versions. Because we are currently stabilizing our central parametric engine, we have made a strategic decision not to plug the old V12 BRX module as a production dependency right now. Introducing an external binary at this critical stage could create a second "source of truth" and lead to dependency hell, distracting us from core geometric validation. That being said, the SQLite philosophy is absolutely a GO for our next development phase, but as a clean data persistence layer structured into a strict three-tier architecture: Data Layer (SQLite): To store externalized project profiles, global cabinet variables (PARAMETRY_SZAF), construction tolerances (PROFILE_KORPUSU), zoning maps (MODULE_MAP), internal equipment payloads (shelves, rods, drawers), and manufacturing logs (BUILD_MANIFEST, BOM). SQLite is the perfect serverless, file-based standard for this, especially with the engine being actively developed (up to version 3.53.2 in mid-2026). Logic Layer (Central LISP Engine): Our pure AutoLISP core that reads these parameters, validates manufacturing constraints, and calculates the exact spatial coordinate plans. Presentation Layer (DWG): The clean, visual 3D output generated by a fully controlled and audited geometry builder. Our Roadmap: We are first finalizing the central engine and rule registry using native, structured LISP association lists (which perfectly mimic the flat row-and-column layout of a relational database). Once the geometry is 100% robust, we plan to write a lean, modern SQLite adapter tailored specifically for our V2B34 schema, completely free of legacy binary dependencies. Thank you for this thread—it completely validated our choice to move towards a relational database structure for complex parametric wood-engineering projects! Best regards, Zen