One of these is an organization the other is a project. Still the name clash is not ideal. Honestly, we’ve tried forever to come up with a different name for JuliaDB, but nothing else has stuck, so in the interest of getting it out there, we decided to just go with the working name that we’ve been using internally. There are three options:
Both the org and the project can use the name “JuliaDB” and they can be disambiguated contextually.
The org could be renamed to “JuliaDatabases”, which is arguably a more apt name.
The project could be renamed to something else – we’re open to suggestions.
An aspect of understanding JuliaDB is that, compared to traditional SQL databases, which are all about transactional storage, JuliaDB is more about persistent computation and bringing code to data efficiently and seamlessly – including being able to store any kind of Julia data without fuss. So the “Julia” part in the name can be thought of as putting a strong emphasis on code.
Do you have any benchmark (or comparison of features) against sqlite, data.table, feather, fst or monetdb?
Not as of now, but we’re working on it. The candidates for comparison we are considering are pandas.Series and xts, (maybe also data.table) which are columnar in-memory databases in the same design space as JuliaDB.jl, rather than sqlite.
[quote=“StefanKarpinski, post:14, topic:3564, full:true”]
Honestly, we’ve tried forever to come up with a different name for JuliaDB, but nothing else has stuck[/quote] DistributedBytes.jl as suggested above?
I think that @ChrisRackauckas was suggesting “Julia Distributed Bytes” as a backronym for JuliaDB rather than suggesting that we change the name to DistributedBytes.jl. Personally, I’d be rather confused if I found a package named distributed bytes and it was a database. OTOH, I’m not sure what I would expect it to be.
I almost feel a non descriptive name like “Pandas” or “Hadoop” or something like that would be best for JuliaDB.jl (i.e. the package). It seems like a product that doesn’t just emulate something that exists already, and it combines a lot of different things into quite a unique, new thing, and I almost feel that any combination of existing terms will just point folks in the wrong direction as to what the package actually is.
Yeah, I was partially kidding to address @davidanthoff’s concerns that the name should have distributed in there. I say partially because I too am at least slightly confused by the name, and at least that interpretation worked .
Sorry for the off-topic but are there any plans for the core team to officially support the low-level libraries for the main relational databases? For example, the most complete PostgreSQL library (https://github.com/JuliaDB/PostgreSQL.jl) is abandonware for almost year and lacks useful features (like pub/sub).
From my perspective, using ODBC drivers for web apps is very rare. I don’t think it’s a common approach with any modern web development stack (certainly not Ruby, PHP, JavaScript, etc). Not even ASP.NET as far as I remember.
But I guess this can be a way to go if we can’t have up to date libraries wrapping the C API. Thanks for the tip.