Lookml Code Editor
You use the lookml code editor to write and test data models inside Looker. Developers switch on developer mode, edit model files, and push changes to Git. Teams often grant broad developer roles so analysts can build reports fast. Broad roles let users query sensitive tables and view raw emails or card numbers. A clear role setup keeps your data safe while analysts build new views. How the lookml code editor works in practice The lookml code editor runs right inside the web browser for your
Infrastructure as Code Security Scanning: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use the lookml code editor to write and test data models inside Looker. Developers switch on developer mode, edit model files, and push changes to Git. Teams often grant broad developer roles so analysts can build reports fast. Broad roles let users query sensitive tables and view raw emails or card numbers. A clear role setup keeps your data safe while analysts build new views.
How the lookml code editor works in practice
The lookml code editor runs right inside the web browser for your analytics platform. It connects your data warehouse tables to shared business rules and metrics. Each developer gets a personal branch to edit files without breaking live dashboards. When an analyst enters developer mode, the workspace loads their private Git branch. They write views that map to database tables and joins that link views together.
As they type, a built-in validator checks the syntax for missing fields or bad references. After saving a change, the developer runs a test query in the explore page. The platform translates the model logic into raw SQL and sends it to the database. Once the numbers look right, the developer commits the code and merges it to production. This workflow keeps metric definitions in version control instead of scattered across spreadsheets.
Managing permissions and branches for model developers
Platform admins control who can open the editor by assigning specific user roles. You can limit a role to read and edit only one project or model set. This separation stops marketing analysts from changing finance logic or reading payroll tables. Teams also set up pull request reviews in their Git provider before merging changes. A senior engineer checks the new logic to catch slow joins or wrong sums.
Still, the editor still needs a live database account to run test queries. In many setups, all developers share one service account for that warehouse link. If that service account can read every schema, any developer can write a view against restricted tables. Even before merging code to production, a test query in a private branch fetches real rows. You must lock down the underlying database permissions, not just the Git branch rules.
Infrastructure as Code Security Scanning: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native editor roles solve and where gaps remain
Native roles in your analytics tool decide which users can open the editor and save files. They also control which project folders appear on the screen for each team. When paired with Git branch protection, native roles keep broken code out of production dashboards. They give teams a clean way to organize who owns which business metrics.
Still, workspace roles only check who logs in and which menus they see. They do not inspect the actual SQL statements that run during a test session. A developer with a valid role can use the SQL runner or a custom view to pull full tables. Native settings do not rewrite sensitive fields like phone numbers or national IDs in query results. They also leave a gap in audit logs when multiple users share one warehouse credential. Security teams need visibility into every individual query and who triggered it.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Can developers edit files outside the browser editor?
Yes, developers can clone the Git repo to their local machine and use any text editor. They push their branch back to the remote repo and test changes in the web interface.
Do changes in the editor affect live dashboards right away?
No, edits stay inside the user's personal branch while they work in developer mode. Live dashboards only update after the developer commits the changes and merges them to the main branch.
How do you stop developers from querying restricted database tables?
You must restrict the database role used by the analytics project or split projects by department. You can also add query controls that check each statement and mask emails or card numbers in results.