kareemmahlees / tablex

Table viewer for modern developers

Hi, I am Kareem Ebrahim

Backend Engineer

Performance nerd, a clean code addict, loves open source, and appreciates developer experience.

I lean towards backend, but I do very well in frontend, Try me!

• 🌍  I'm based in Egypt
• 🖥️  See my profile at LinkedIn
• ✉️  You can contact me at [email protected]

Skills

Socials

Badges

My GitHub Stats

tablex's Issues

Cannot connect to local PostgreSQL DB running in docker

Description

I have been trying to connect to a PostgreSQL database running in Docker.

Using the PostgreSQL driver, the connection Test button is working (and reporting a successful test). Clicking on the Connect button, nothing happens (no visual errors).

The behaviour is replicated on local running the project with pnpm tauri:dev (using the setup instructions listed in the contributing guidelines for this repo). No errors are visible in the tauri backend side of the project. The frontend shows the following error in console:

[Error] Unhandled Promise Rejection: No such file or directory (os error 2)
	(anonymous function) (index.esm.mjs:2215)

I suspected that it might be caused by invalid host settings, so I tried:

• 0.0.0.0
• 127.0.0.1
• localhost
  for the host value, and get the same response.

Lastly, I also tried using the DB connection string option (again with different host variants as above) and no luck.

Running docker ps (to confirm docker/db setup) in terminal gives the following (I realise that the DB type is a timescaledb container. I can confirm however that I am getting the same behaviour using a "normal" pg database):

CONTAINER ID   IMAGE                               COMMAND                  CREATED       STATUS       PORTS                                       NAMES
3bdbec6b4163   timescale/timescaledb:latest-pg16   "docker-entrypoint.s…"   3 weeks ago   Up 3 hours   0.0.0.0:5439->5432/tcp, :::5439->5432/tcp   pih-rs-db

Using other tools (such as DataGrip and DBeaver) I can successfully view/access the database as expected.

Environments

• Latest release
• Local (running project using pnpm tauri:dev

System Info

• macOS Sonoma 14.2.1
• Docker version 25.0.3, build 4debf41

Hope that this helps :)

No back button

I noticed when I pick one connection I didn't see any way to navigate back, like close that connection and return to the connections menu, without closing and reopening the TableX app. Should there be some way to close connections and navigate back?

TableX ignores cli arguments

If you try to pass command-line arguments to the table-x executable, it completely ignores any arguments you type after the command name and just opens the app normally.

For example, if I execute:

table-x --help

instead of showing command help, it just silently ignores the --help and opens the app UI as if I'd executed just table-x.

SQLite driver should support all common SQLite file extensions

Currently the file picker for SQLite engine uses a "DB File" filename filter that ignores any file extension but ".db". Wikipedia:SQLite lists several other common extensions besides ".db": .sqlite, .sqlite3, .db, .db3, .s3db, .sl3. Could all those be accepted by the file picker?

Performance issues with large databases

Description

I am back :) After #28, I can now successfully connect to my DB. However, I have noticed some performance degradation when the target DB has a lot of data.

For context, I have a TimescaleDB database for storing IOT sensor data. Currently, the table has around 25 000 entries, and is only growing by the hour.

I saw in the tauri code, that the data is being retrieved by doing a SELECT * , which does make sense for smaller amounts of data. Now I do realise that this might not be the exact "target market" / use case for TableX (to view data in DBs with large amounts of data), but it would still be cool to use it.

Now I must confess, I'm not super well versed in Rust, so at this stage I don't have a proposed solution, apart from ideas:

• Perhaps the get_rows data retrieval function can somehow be paginated? I am not sure if SQLx even provides a way to do this. Even so, I assume it would require a bit of a rethink on the data retrieval queries/functions.
• This could be applied to the frontend as well, as the frontend seems to struggle with such large amounts of data. Perhaps some form of virtualisation in the rendering of the table rows could be a possible solution? Or at the very least, having paginated data being retrieved from Tauri could also help with initial performance concerns.

I am definitely keen to helping come up with solutions/doing research on possible solutions, so let me know :) Or, if this is out of scope of your vision for TableX, that is also (obviously) perfectly fine :)

For debugging purposes, here is my docker-compose.yml setup:

version: "3"
  db:
    container_name: pih-rs-db
    image: timescale/timescaledb:latest-pg16
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "5439:5432"
    restart: always
    volumes:
      - db:/var/lib/postgresql/data

volumes:
  db:
    driver: local

I have a (still very, very incomplete) Axum project that uses the docker setup mentioned above. If you want/need more information on the DB schemas & structure of the tables to help with creating/setting up a similar DB setup, you can check the initial migration file

Build fails with "couldn't find a square icon to use as AppImage icon" for commands like `pnpm tauri:debug`

When I run pnpm tauri:debug or pnpm tauri:build on a fresh checkout of the tablex repo, I get an error about missing icons:

❯ pnpm tauri:debug

> [email protected] tauri:debug /home/david/projects/tablex
> pnpm --filter @tablex/core exec tauri build --debug

     Running beforeBuildCommand `npm run build`

> @tablex/[email protected] build
> next build

   ▲ Next.js 14.0.2

 ✓ Creating an optimized production build    
 ✓ Compiled successfully
 ✓ Linting and checking validity of types    
 ✓ Collecting page data    
   Generating static pages (0/8)  [=   ] ⚠ Entire page /dashboard deopted into client-side rendering. https://nextjs.org/docs/messages/deopted-into-client-rendering /dashboard
 ⚠ Entire page /dashboard/details deopted into client-side rendering. https://nextjs.org/docs/messages/deopted-into-client-rendering /dashboard/details
 ✓ Generating static pages (8/8) 
 ✓ Finalizing page optimization    

Route (app)                              Size     First Load JS
┌ ○ /                                    1.61 kB         111 kB
├ ○ /_not-found                          871 B          85.4 kB
├ ○ /connect                             8.12 kB         164 kB
├ ○ /connections                         4.19 kB         143 kB
├ ○ /dashboard                           175 B          89.7 kB
└ ○ /dashboard/details                   25.8 kB         175 kB
+ First Load JS shared by all            84.5 kB
  ├ chunks/399fa1b5-64be7eb8847af37b.js  53.3 kB
  ├ chunks/51-359ff64d79f27c7c.js        29.3 kB
  ├ chunks/main-app-acc7200bd005946d.js  219 B
  └ chunks/webpack-dd335d907f2bea33.js   1.69 kB


○  (Static)  prerendered as static content

   Compiling tauri v1.5.4
   Compiling tauri-macros v1.4.3
   Compiling table_x v0.1.0 (/home/david/projects/tablex/apps/core/src-tauri)
    Finished dev [unoptimized + debuginfo] target(s) in 15.13s
    Bundling table-x_0.3.1_amd64.deb (/home/david/projects/tablex/apps/core/src-tauri/target/debug/bundle/deb/table-x_0.3.1_amd64.deb)
thread '<unnamed>' panicked at /build/tooling/bundler/src/bundle/linux/appimage.rs:73:6:
couldn't find a square icon to use as AppImage icon
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Seems to be tauri-apps/tauri#749. The other pnpm tauri:dev command runs fine.

Migrating the frontend from NextJs to React + Vite

Motivation

Currently we are using Nextjs in the frontend, but we are not actually using any of Nextjs's features apart from the file based routing.

Nonetheless, It is actually introducing limitations, I spent a good 3 hrs trying to make Tauri's splash screen work with Nextjs but with no use.
Also Tauri invoke commands cannot be called inside of server components.
And also we are not using API routes.

The Solution

The solution is to migrate to just plain React + Vite and use Tanstack Router for routing ( which also offers file based routing, doing this will allow use to better handle problems and fill the missing gaps.

How to approach this

• Initialize a new react project inside the apps folder and name the package @tablex/react-front
• From her and on it will be just plain coping and pasting components
• As for Tauri invoke commands, you can import the commands from the apps/core/src folder until we have finished migrating.
• move lib, components and all other logic into the new project but this might be a good time to introduce some refactoring to how the code is structured
• And at last, delete the old nextjs folder and replace it with the new react folder

Support cli args to establish DB connection

Could there be an option to pass a DB path to TableX as a cli argument and have it directly open into a connection to that DB path, as an alternative to opening to the landing page and then going through the UI to "Start a connection" > "Select a Database Driver" > enter connection details > "Connect"?

For example, allowing you to run commands like:

table-x mydb.sqlite
table-x postgresql://localhost:5432/mydb

?

Performance: App is sometimes slow to close (takes several seconds)

I've noticed the app is surprisingly slow and in some cases even takes several seconds to close after I click the X button.

There's no noticeable delay if I just open the app, wait for the main UI to load, and then click X. If I start a SQLite connection and then close the app, it does seem to consistently hang for a couple seconds (which could conceivably take a little time to close a DB connection, but still feels excessive taking several seconds in the case of a local SQLite file). But also even if I just start the connection dialog for a SQLite connection, quit out of the file picker, and close the app, that still seems to take the same several seconds to exit... in that case I can't imagine why.

Migrate the website to Astro

Context

Currently, the website is built using Vite + React but rarely uses any reactivity or client-side interaction, so, it is a situation where using Astro seems reasonable.

Approach

This would be a one-to-one translation using Astro client directives for the reactive parts.

How to start working on that considering the current monorepo setup

It will be easier to create a separate package, call it for example astro-website, and add the astro:dev, astro:build, and astro:preview commands in the root package.json, basically it is the same how it's done in the original website.