NoSQL and document databases like MongoDB have made building fast, scalable software that is easy to evolve and maintain much easier for a broad class of applications.
Embeddable, file-based databases like SQLite have made shipping an application that requires a database a no-brainer.
The database just runs in process, so there's no setup or maintenance.
Yet, when you try to intersect these two excellent capabilities, you'll find the options are very limited.
There just aren't many embeddable document databases.
If you're a Python developer and you want a native Python solution, the options are much slimmer still.
That's why I'm excited to introduce you to Marcus Siemens and TinyDB.
TinyDB is a 100% pure Python, embeddable, pip-installable document DB for Python.
This is Talk Python to Me, episode 80, recorded October 13, 2016.
Welcome to Talk Python to Me, a weekly podcast on Python.
Thanks for listening to my podcast.
I've heard from so many of you that the insight into the industry you gain from each week is very important to you.
I want to take this moment and tell you about my online courses for those of you who want to go deeper and convert your enthusiasm to working knowledge.
At Talk Python, we currently have three courses available.
Python Jump Start by Building 10 Apps, for those of you who are just getting into Python.
Write Pythonic Code Like a Seasoned Developer, covering over 50 hard-won coding tips.
And Python for Entrepreneurs, available for early access already, covering web development, design, and everything else you need for an online Python-based business.
See these courses and more at training.talkpython.fm to hone your Python skills, no matter your experience level.
Now, I hope you enjoy this week's interview.
Marcus, welcome to Talk Python.
Thanks for having me.
Yeah, it's really great.
I was talking to Austin, I think it was show 63, possibly, about mutation testing.
And he said, I'm doing this really cool work with mutation testing.
Oh, and for the database, I'm using this cool, embedded, document-oriented database called TinyDB.
And since then, I was like, wow, an embedded document database?
How awesome.
And it's 100% in Python.
So even cooler.
And since then, I've wanted to have you on the show and talk about it.
So welcome.
Yeah, thank you.
Yeah, it's going to be fun to talk about this database.
It's tiny, from what I can tell.
It's great.
Yeah, it is.
But before we get into that, of course, let's talk about your story.
How did you get into programming in Python?
When I was about 10 years old, I kind of got into programming because my dad bought me a book called C++ for Kids.
I was 10 years old.
I didn't really understand much.
I just copied the examples and made sure it compiled.
And that was basically it.
So later when I had a book, Python for Kids and Java for Kids,
then with around 14 or 15 years, I started really doing some programming in Java on my own.
So that's when I actually got really started with programming.
Cool.
And what were some of the first apps you built with Java?
What kind of work was that?
My first application was a Hangman implementation in Java.
So I had some problems with how I structured the code because I had to make everything public static in Java.
So it compiled.
And then something didn't work and I asked my dad for help.
And he was horrified when he saw the code because everything was public static.
And he then helped me out with sorting out where to pass an object and so on.
So, yeah, I got some help from him.
And, well, that's how I first got into working with Java.
And a couple of years later, I applied to university to study electrical engineering.
And before that, you had to do an eight-week internship.
So six of these weeks at a small company, which mainly sells servers, which they sell servers with support contracts for enterprises.
And they asked me to create an application so they can configure the servers via the web.
And the project was they asked me to do it in Python.
So that's how I got started with Python and wrote my first serious Python code.
That's cool.
And what was your impression?
Were you like, oh, yeah, Python's awesome.
Or were you like, whoa, where'd public static void go?
Where'd public static go?
Yeah.
It was, I think it was way easier than I expected.
Because after like one or two weeks, I was already quite confident that I could do the whole project.
So I didn't really have any experience beforehand with Python.
And with that project, after one or two weeks, I was really confident that I could do the whole project without big problems.
Yeah, that's great.
Very nice.
I find a number of people get into Python that way.
They're like working on some project and people come along, their co-workers or boss or somebody.
will say, hey, can you do this thing in Python?
They're like, Python?
Well, I don't know anything about it, but let me give it a try.
It turns out to be really easy.
So that's really great.
Yeah, it is.
Definitely.
It's very easy to start.
And I would say it's one of the best programming languages to learn programming.
Yeah, I certainly think it is as well.
In the United States, they used to teach Java as the primary computer science 101.
First course, you take programming languages.
And in the recent years, it's switched to be primarily Python.
So that's great.
At my university, people have to start with C and C++.
And most people have quite a lot of problems with that.
And I guess it would be kind of an easier route to go with Python first.
But I don't know.
It's their choice.
Yeah, of course.
I think there's something to understanding a C-oriented language where you actually work
with pointers and directly with the memory and stuff.
But I'm not sure you should start there.
You know what I mean?
Yeah, it's your very first exposure.
Just for comparison, my first computer science 101 course in college was Lisp.
So that was really different.
All right.
So that's how you got started.
What do you do day to day?
University, I'm still studying.
And next week, my lectures start again.
Till then, I do some freelancing work, mainly web development.
Nice.
And is that web development in Python?
No, it isn't.
It's mainly JavaScript.
Right now, I'm doing some front-end development, which is mainly JavaScript.
And sometimes I wish it were Python, but I can't always choose.
That's right.
Sometimes if there's good work to be done, you just got to go do it.
All right.
So the database that you created called TinyDB is a document-oriented database.
And that falls into the realm of NoSQL databases.
And so just for everyone out there listening, I realize many of you know, but maybe some
of you don't really totally know the difference between, say, relational databases and NoSQL
databases.
So relational ones, I think we're all pretty familiar with.
There's a bunch of tables.
There's foreign key relationships between them.
We try to normalize our data, minimize duplication, and sort of set it up for querying from any
particular angle, right?
You have a wide range of queries you can write.
But in the NoSQL world, there's a different set of trade-offs that those databases are making,
right?
Like the document databases don't have as much of a flexible set of queries you can write.
But if you build the documents right, you can really optimize them for exactly the use case
that you're looking for, right?
So your data is more hierarchical and more directly models like how you might actually want to work
with objects and relationships in your code rather than in storage.
So there's also other ones like key value stores and even graph databases, although in my mind,
those are not NoSQL databases.
That's a different debate for a different time.
Yeah, it is.
Yeah, but so yours, TinyDB, falls into this document database.
So why don't you tell us, what is TinyDB?
Yeah, TinyDB is, like you said, a NoSQL, basically, a database.
And actually, I didn't plan to do a NoSQL database.
I just plan to do something that is easily usable.
I happened to write TinyDB for another project, which was in total, I think, like 300 lines.
And I didn't really feel like doing SQLite or SQLite database for it, because if I had to change
anything about the data structure, I would have to write migrations and so on.
So I just wrote a really simple database with a bunch of dictionary objects, which contain the data,
and then added some query language for it.
And it happened to become quite popular.
Yeah, that's really cool.
And it is quite popular.
It's got over a thousand stars on GitHub, which is very cool.
Yeah.
You must be proud of that.
That's great.
Yeah.
What was interesting is that I didn't really do any marketing or promotion at all.
I just put it on GitHub, uploaded some documentation, and just left it as it was.
And after a couple of months, I got the first issues.
And like a year later, I got the first pull requests without any involvement on my side,
which was really a real great example of open source, how it works.
Yeah, that's a great validation that people see what you've made, and they actually want to contribute back.
You're like, wait, what?
Yeah.
Where did this person come from?
They are working on my project.
How great.
Yeah, that's nice.
You made a really interesting comment when you described why you didn't want to use MySQL or SQLite,
whichever one you were referring to.
And that's, you don't want to deal with migrations and all the headaches of evolving your schema.
And I think one of the really, really powerful things about document databases that you don't really appreciate until you try it
and you've sort of lived with an application over time is the ability to easily evolve the schema, right?
Like if you want to add a field, you add a field to either your dictionary or class in your application,
and that just becomes part of your schema.
It's usually much easier, I think, to maintain these applications that are based on document databases.
That's my experience anyway.
Yeah.
It was my experience too with the project I was working on originally because I didn't really know how the data would look like.
So I needed something that would allow me to change the data as I need or as I find out I need another field so it wouldn't be hard to edit.
Yeah, absolutely.
And I think it's really cool that you have this as an embedded database because I would say probably the most popular choice for these types of databases would be MongoDB.
But then you've got to deal with another server and, you know, configuring that thing and the connections.
And just, you know, sometimes you just want a small embedded thing that's just part of your app.
Yeah.
What I really like about SQLite is that it's embedded so you don't need any server, you don't need any maintenance or anything.
So basically Python, basically TinyDB combines the best of SQLite being embedded and MongoDB being a document database.
Yeah, that's really cool.
So you said it's written 100% in Python.
How many lines of code is that?
Yeah, it's about 1,200 lines of code of which 40% approximately are documentation.
And in addition to that, like 1,000 lines of test code.
That is awesome.
Yeah, and you have 100% test coverage as well on your project, which is really nice when you've got something that's actually managing your data.
You want to be really pretty sure that it's working right, yeah?
Definitely.
Okay, so if it's 100% in Python, how do I get it into my application?
Like, can I pip install it?
Yeah, definitely.
Installing should be very easy.
Just run pip install TinyDB, and then you just have to open a Python repl to get started, import TinyDB, and basically you are ready to go.
Yeah, that's really nice.
And so there's no server to start, like if your app is running, the database is running, right?
Yeah.
Yeah, yeah, very cool.
So you had some reasons why you should use TinyDB and some reasons maybe why you might not.
So what use cases are really good for considering TinyDB?
I think it's just like the project I was working on originally.
I think it works best for small projects where you don't really have or you don't really want to use a bigger database.
So a small web application, I think some guy used it for a password manager or something.
So really projects where having MySQL database or something like that would just add too much complexity.
Yeah, certainly if you're going to deploy an application or library and you don't want to have the getting started steps, say,
now you need to set up this server and you need to run this script to build this schema,
and then you need to set the connection string here, and then you can get going, right?
So to me it feels pretty similar, not an exact fit, but similar to, say, SQLite, when you might use SQLite.
Yeah.
It's similar in that you can really easily get started and you don't have to manage a server or something like that.
Sure.
So because it is a pretty small database, it doesn't try to do everything, right?
It's not like MongoDB rewritten in an embedded Python variation.
It really does do less.
So there are some things it doesn't do, and maybe if you really depend upon them, you should not focus.
You should pick something else.
What are those cases?
Just so we know people can decide if it fits for them.
I think the main disadvantage of TinyDB is when you're using multiple threads.
In that case, there is an extension for TinyDB you can use.
If you have multiple processes, then you are really out of luck because there is no type of locking the file you're writing to.
So you would probably run into issues with that.
And also, it might turn out to be a bottleneck in performance.
If you have hundreds of thousands of entries in your database and you search them, because TinyDB doesn't have any kind of index, it will have to scan the entire list every time you do a search.
So you probably shouldn't do really involved data processing with it.
Okay.
Yeah.
And that definitely, some of those are serious.
Some of them might not be.
It depends on your use case, right?
Now, I don't want to talk about it yet.
We'll get to it.
But there's a bunch of extensions.
And I think there are some that will come and solve some of those performance problems, which are interesting to some degree.
And also, they open the possibility for a listener, an enterprising listener out there, to come and add something like multi-process or multi-thread support, things like that, right?
So we'll get to the extensibility.
There are a number of extensions now.
I hope it's quite easy to add a new one.
So if there are a couple of things where TinyDB doesn't support them out of the box, but if you want to, you can write an extension, you can write your own storage mechanism, and so on.
Yeah.
Great.
Yeah.
We'll talk about that in a little bit.
Awesome.
So when I think of competitors, you have a few listed, and we've talked about a couple of them.
Competitors, like we said, is not exactly the right word because it's all open source, but choices you might choose from.
On one hand, like MongoDB, if you're doing document databases and you're doing real large data production apps, maybe this is, you want to scale out, maybe this is the right choice.
But there's also some other pure Python databases that I had not heard of that I thought were pretty interesting.
So do you want to tell us about the two that you listed on your site?
What are their names?
Before starting with TinyDB, I first did some research if there already is some kind of embedded Python database I can use, and that fits my use case.
And there wasn't really, I found two projects which are somewhat similar, but not really.
For example, there's a project called CodernityDB, which is also pure Python and NoSQL.
But as far as I know, it's much more complex.
You have the ability to use indexes.
You have HTTP support.
So it might be a great fit for a project.
But in my case, it was just too much code.
I think it's like 7,000 lines of code, which would be seven times the size of my project.
So, yeah.
And I think that's without unit tests, the size of the code.
So it's even bigger, yeah?
Yeah.
And the other one was BuzzHug.
BuzzHug is also quite interesting because it's optimized for speed.
But what I didn't really, the reason why I didn't use BuzzHug was that it didn't have the kind of query language I wanted to use.
So while it is really fast and it's also pure Python, it just didn't have API in the way I wanted to have or the kind of API I imagined to use.
So I chose to build my own project.
And also, it's like twice the size of TinyDB without tests.
Yeah, definitely.
So the CoderityDB, that one is a key value store.
So in some ways, maybe not quite as capable as the document databases.
It depends.
They do have some additional indexes and queries you can write.
But maybe not quite as flexible.
And then BuzzHug is relational.
So you have, again, all the trade-offs with managing the schema and evolving it in migrations.
So, yeah, to me, it feels like SQLite is kind of the biggest competitor to you, you guys.
Yeah.
Yeah, cool.
So can you maybe, I don't necessarily want to talk about code exactly in audio format because that doesn't usually go so well.
But just give us a sense of, like, what is the API like?
Like, if I wanted to create, you know, get started with TinyDB, I wanted to create a database and insert some records.
Like, what does that look like?
Yeah.
So you start with importing TinyDB.
And there are two main classes you will probably use, which is the TinyDB class and the query class.
So you basically create a new instance of TinyDB.
And you already have your database.
You don't need any for the setup code or anything.
And then you can just call DB.insert or the instance and call the insert function, pass some Python dictionary, and you already inserted your first object into the database.
Yeah, very nice.
And so it just basically, you either can directly or into a table insert more or less Python dictionaries, right?
Yeah.
And basically, you have all the basic functions, create, read, update, and delete.
You can do some interesting searching.
Search for objects with specific parameters.
You can do some quite involved searching with the API I provided.
But yeah, I think besides the database itself, the query language is like the second biggest or has the second most code in the whole project.
If you have a list, you can search for an item in that list with specified properties and so on.
So if you want to, you can really go crazy with searching.
But still, the basic API is insert, delete, and then, of course, querying and update.
Yeah, nice.
And to me, the query language looks a little bit like SQLAlchemy in that you do it sort of in a Python language and it's translated to the query that goes down to the system, right?
I actually found out about the SQLAlchemy project.
I think I just discovered it.
After I wrote TinyDB, so it happened to have a very similar query language.
Yeah, you didn't take it straight from there.
But it is a very natural way of doing it.
So basically, the fact that you use the native Python sort of equality and things like that and then it translates it over is really nice.
The exchange of data, if you just go against your API directly, is really in dictionaries.
And sort of extended a little bit with your primary key being on there as a separate type of attribute and so on.
But more or less as dictionaries.
Is there an object data mapper layer, kind of like Mongo, has Mongo Engine or Mongo Kit, where you work in higher level stuff?
Like I would write, say, like, here you have, in your example, you had a person.
Like, could I create a person class and maybe put rules or columns or structure on that and then use that to query with?
Yeah, in a way, you can already use the query language of TinyDB as an ORM.
So you can create a new instance of the query object and call it user.
And then you can call something like user.name equals to the name you're looking for.
And you already have a query, which you can use to search the database.
So you can do that or use that as some kind of ad hoc modeling.
Okay. Yeah, nice.
And do you support Python 3?
Python 2?
What versions of Pythons do you support?
I tried or I still try to support as many versions of Python as possible.
I'm not sure about Python 2.6.
But upwards from Python 2.7, I think I support every version.
Also because TinyDB doesn't have any external dependencies even on other Python packages.
So it's quite easy or it was quite easy for me to write code which works in both Python 2 and 3.
So if you're using Python 3 or Python 2, either way, you're good to go.
Yeah, that's really excellent.
So I'm very happy to see the increased Python 3 support for your project, other projects.
I had the Bware guys on last time and they're like, it's all Python 3.
So that's great.
The other thing, if it's pure Python, the very next question I had was, well, if it supports Python 3, what's the story with PyPy, the JIT compiled version of the interpreter?
I didn't myself really use it with PyPy, but I still run every commit I do with continuous integration, which tests all the Python 2 and 3 versions and also tests that it works with PyPy.
But myself, I didn't really have a use case where I would need to use PyPy.
So I don't know if it's faster or slower than you would expect.
Okay.
But it definitely works.
It definitely works.
Okay.
That's really cool.
And so maybe it's a lot faster.
Actually, we'll get to some stuff that talks a little bit about speedups that you can do.
And maybe that just takes PyPy out of the loop in terms of being necessarily important.
But anytime you have something like this that's pretty central to how your application performs and you can do it on PyPy, that's pretty interesting to see.
This portion of Talk Python to me is brought to you by Hired.
Hired is the platform for top Python developer jobs.
Create your profile and instantly get access to 3,500 companies who will work to compete with you.
Take it from one of Hired's users who recently got a job and said,
I had my first offer on Thursday after going live on Monday, and I ended up getting eight offers in total.
I've worked with recruiters in the past, but they've always been pretty hit and miss.
I tried LinkedIn, but I found Hired to be the best.
I really liked knowing the salary up front.
Privacy was also a huge seller for me.
Sounds awesome, doesn't it?
Well, wait until you hear about the sign-in bonus.
Everyone who accepts a job from Hired gets $1,000 sign-in bonus.
And as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python to me and Hired will double the sign-in bonus to $2,000.
Opportunity is knocking.
Visit Hired.com slash Talk Python to me and answer the door.
Speaking of that, one thing that I saw that was cool, and this is something I learned today,
I hadn't really paid any attention to it before, is you said one of the speed-ups you can do is,
if you install a package called uJSON, you can get TinyDB to run a lot faster.
Because as you can imagine, it's all about JSON parsing, multi-directional JSON parsing, right?
And so what's uJSON and why is it faster?
uJSON is a really cool project.
I think the main or the reason why JSON parsing matters so much is that basically due to the way TinyDB works,
every time you do, every time you interact with the database, you have to read the database file from the file system.
So you really need a fast JSON parser.
And the JSON parser that comes with Python is really powerful.
You can extend it in a few different ways.
But if you really need performance, this kind of extension really only gets in the way,
because probably to implement it in Python, the whole parsing,
and then you lose a lot of speed.
So uJSON is one project I found, which also implements Python,
I mean, which also implements JSON parsing,
but it does it all in C.
So it's really fast.
You do have a trade-off that it's not as extensible.
But if you don't need to overwrite some internals of the JSON parser,
then it's really good to use uJSON to get more performance out of it.
Yeah, that's really cool.
And you can just pip install that.
And you said that TinyDB will look for its existence and prefer it if it's there.
But if it's not there, it's fine.
It'll just use the standard library JSON, right?
Yeah, so if you install it, it works like a drop-in.
You just install it, and Python and TinyDB auto-detects it,
and you get the speedup instantly.
Yeah, nice.
Let's talk about extensibility a little bit.
So there was a couple of things I asked about,
and you're like, well, I'm not sure it's really in there, maybe.
But you've written a pretty cool framework for extending TinyDB.
And so some of the things you can extend are like you could write a custom storage engine.
You can write custom middleware, custom table classes.
And then there's a bunch of projects that people have written that then you can plug into TinyDB to make it nicer, faster, etc.
Yeah, extensibility was something I first started with having support for multiple storages.
So you could swap out the JSON storage and use memory-only storage.
I decided to provide even more extensibility so you can write a middleware,
which modifies the way TinyDB works with any kind of storage.
And also there are quite a bit of extensions out there you can use to modify TinyDB works in total.
So there's a bunch of extensions, and one of them is TinyRecord.
What's the story of TinyRecord?
TinyRecord was basically written because TinyDB itself didn't have any real support for multi-threading.
So with TinyRecord, you basically have some sort of transactions and also uses locking.
So you can use TinyDB from multiple threads.
And then you have an object where you can add a bunch of modifications you want to use.
And yeah, basically it's transaction support for TinyDB, which is quite handy if you need multi-threading.
It depends on your use case, of course.
Yeah, of course.
But if you need it, that is really cool.
So another one that someone wrote, these are all separate projects on GitHub, by the way.
Another one that somebody wrote is called TinyMongo.
Yeah, TinyMongo.
So does that like match the MongoDB API or something, but then actually store it as through TinyDB?
Or what's the story with that?
Yeah, TinyMongo, as far as I know, allows you to use an interface or an API which matches the MongoDB,
API, but instead uses TinyDB.
I think one day I just got an issue on GitHub where someone said, hey, I have this extension
for TinyDB so it can replace MongoDB.
And I included it into the list of extensions.
Yeah, that's really cool.
So it does look like it more or less just replaces the PyMongo API.
So you've got like insert and find one and it even has like the dollar operators.
So like dollar set and so on.
Yeah.
So one of the things that comes to mind for this for me is because TinyDB stores its files,
at least by default, in a simple JSON document and there's no setup for it.
If you were doing unit testing and you needed something better than just simple mocking
and studying out your test data against MongoDB, it might be cool to switch it to this and use
this as a way to kind of have a slightly better test backend for a real Mongo system or something
like that.
If you don't want to start up a separate server just for testing, that might be a really cool
solution for that problem.
Yeah, nice.
So then there's a couple of others.
One is TinyDB serialization.
And I noticed that when I was playing around with TinyDB that I, for example, put like a
date time in as part of my record.
And of course, you can't, people may or may not know, you can't just go to the JSON module
and go save this thing if it has a raw date time in it.
It just, it doesn't support it.
And that's what happened when I tried to save my thing in TinyDB.
So does this address that kind of problem and other stuff?
Yeah.
I even think that touring date time objects was the reason why the extension came into
existence.
Because for TinyDB to tour other objects than dicts or for the JSON module really to support
it, you have to modify it yourself.
So the extension allows you to register your own serialization code.
So you can store all kinds of objects that you want to store.
And it allows you to specify how exactly it will be stored.
I see.
So I can, I can basically tell it like, hey, if you see a date time, serialize it like this.
And if you see some other type that it doesn't necessarily know about, store it like that.
Okay.
Yeah.
Very nice.
What about TinyDB SmartCache?
It's also a really interesting project.
I think it was created after a pull request or actually, yeah.
So there was an addition to TinyDB because as I said before, searching can get really slow
if you have a lot of objects.
So what TinyDB does is that as long as you don't modify the database, it stores the results
of your search queries.
So it doesn't have to redo the work if you didn't change anything at all.
So really handy in some cases.
So if you do like a query and you give it some parameters and it comes back with 20 records,
the SmartCache will say, if I see this query again, just give them those 20 records and more
or less.
Actually, TinyDB itself will already do that caching for you.
So what SmartCache does is that if you basically takes it one step farther, if you search query,
it stores the result.
And then if you do some updates on the database, it doesn't throw away the search results, but
instead replaces them or updates the cache with the new results.
So if you have a query which matches some elements and if you insert a new element which also
matches that query, it will go directly to the cache.
So it doesn't have to redo the host searching, which TinyDB itself would have to do.
But of course, it's also a trade-off because it uses more memory, because it has to show more results and also do more.
There is some overhead on every insert and update because it has to check every query if it matches and update the cache in place.
Yeah, but in some cases it can really be a really handy thing to use if you have a lot of updates and deletes in your code and you don't want to redo or to process all the entries in your database for every search.
That might be an extension you want to use.
Okay, yeah, that sounds really cool.
Very nice.
So let's also talk a little bit about the extensibility.
So you said there's three basic places that we could extend TinyDB, and one of them is writing a custom storage engine.
So by default, it's just a single, your data is more or less stored in a single JSON file.
And that's more or less the connection string when you create the database, right?
You say, here's the file.
Yeah, you just pass the file name and it uses it.
Yeah, nice.
Again, very SQLite-like.
But then you said you can create alternate storage engines.
And this got me thinking about some ideas.
But there are some that you talked about already, right?
Yeah, for example, there is a storage which uses or just stores the data in memory.
The first storage I wrote even was for YAML.
So you have these YAML files later switched to JSON because it was faster, because YAML can get really complex in some cases.
If you get really fancy, you could even do some kind of HTTP stuff.
But I don't think that there is an extension for that yet.
But that would be something really interesting to try.
Yeah, absolutely.
And so when I saw this, I was thinking, well, okay, maybe there are certain things you can do to leverage some of the shortcomings that you had talked about when you're like, maybe not so much from multiple process, stuff like that.
So, for example, MongoDB recently switched from storing binary JSON in a variety of files to something called WiredTiger, which is apparently much faster.
And they support multiple processes from there through certain types of locking and so on.
I was thinking, hmm, could you take one of these storage engines and somehow, you know, with some work, plug it into TinyDB?
Yeah, that should be possible.
Writing a custom storage is really easy because you just need to create a class with a constructor, which takes the parameters you need to create the storage.
And then method for reading and one method for writing the data to the storage.
So you could do some logging there.
I think that would be an interesting thing to do, logging on storage level.
So basically, then it has to wait until the database file itself is locked or unlocked to return the data.
That would be interesting.
It would be interesting, right?
And so, I mean, it definitely seems like you could unlock some potential there as well.
Okay, cool.
So custom storage engines.
And you could even do crazy stuff, right?
Like you could say, I'd like to use an S3 bucket as my storage location or those types of things, right?
Whatever you're looking at.
As long as you can read it and write it, it should be possible to use it as a storage.
Interesting.
Okay.
The other thing you talked about was custom table classes.
What's that?
Yeah, custom table classes mainly came into existence to modify the way the database implementation works.
So it's basically in other cases you would have to over or to use a subclass.
And so with custom table classes, you basically what you do is have a subclass of TinyDB.
And then you can really do a lot of modifications.
For example, the smart cache extension uses a custom table class to provide or to intercept every insert, update, and delete, and so on to add its own logic behind it.
Okay.
Could you use something like a custom table class to say, like, this field is required?
Or this one must match like some kind of constraint, like it must be an email address or something like that?
And then like not let it insert if you tried to save the wrong one?
Yeah, that's definitely an interesting idea.
Yeah.
That would be a really interesting extension for our TinyDB validation because you can intercept all the in-source and updates.
And then you could check if it matches and raise an exception if it's not valid.
Yeah.
Yeah, that's really nice.
The other way, I guess, that we haven't really spoken about yet is middleware.
So what kind of things can you do with regard to extensibility and middleware?
Yeah.
Middlewares are the third way to do modifications or to modify the way TinyDB works.
Basically, it acts as a layer between TinyDB and the storage you pass to it.
So you can do some interesting things over there.
For example, in TinyDB, there is a caching middleware, which provides a way so it doesn't have to hit the file system on every read and write.
Only every couple of reads and writes.
So you don't have that overhead.
And yeah, so you can do some modifications there, different ones from a custom storage.
I think the main way in which middlewares are interesting, because you can use multiple of them at the same time.
You can use it with any kind of storage behind it and do some modifications over there.
Yeah.
For example.
Yeah.
Okay.
Very cool.
So what's the future of TinyDB?
Have you got anything you're adding or anything like that?
I don't really have any big plans for TinyDB.
I think right now I'm quite happy with how the project works and how the API is looking like.
There might be some renaming of methods.
So the intent of the method becomes clearer.
But apart from that, right now I don't have really any big plans to change how it works.
Because, I mean, the project itself is quite small.
So there's not much I would want to add into the TinyDB core itself.
But of course, there's still room for a lot of extensions to write.
Yeah, that sounds great.
Are you looking for people to create extensions or suggest changes or basically open source contributors?
Yeah, I think writing extensions for TinyDB can lead to some really interesting projects.
As we already talked about a couple of extensions.
And apart from that, I'm always glad if people have improved the documentation.
Because I'm not a native English speaker.
So there might be a few rough places in the documentation.
So if people think that the wording might need some improvement, I'm definitely happy to accept that pull request.
And also, if you write an extension, just open an issue on the project on GitHub.
And I will add it to the list.
Okay, excellent.
Well, I think it's a very cool project.
I would love to see a nice, robust, embedded document database.
So thanks for taking us a little closer to that world.
Yeah.
Awesome.
All right, so before I let you go, I have two quick questions for you, as always.
So first of all, you're welcome to name your own stuff if you want.
What's your favorite PyPI package?
I just noticed we now have over 90,000 PyPI packages.
And so you must have some exposure to a few that are pretty interesting.
Yeah, I think the package I would recommend is the one we already talked about, which is uJSON.
Because in many cases, it can improve performance by a lot.
Without, if you don't need to customize the way the JSON parser of Python works, then using uJSON can be really cool.
Yeah, that's great.
And so many people are processing JSON in one way or another these days.
So it's very broadly applicable.
A good choice.
I'll throw in TinyDB for you as well.
So pip install TinyDB.
And how about your editor?
If you're going to write some Python code, what do you open up?
It depends on the project, really.
For small projects, I probably use sublime text.
But if it's more than two or three files, I probably fire up PyCharm and use it.
Okay.
Also because, yeah, that's an interesting development in Python with gradual typing.
It's high-pins.
Yeah.
And PyCharm, as far as I know, already supports them to some extent.
So it's really handy for that as well.
Yeah, that's really cool.
If I'm trying to understand some code and I'm like, oh, these three things that are coming in are these types.
If you tell it, it'll give you a lot more assistance trying to understand something.
If you're jumping into something you don't totally know the API for, that's cool.
All right.
Yeah.
Awesome.
PyCharm is a good one.
So sublime text.
All right.
Final call to action.
People should get out there.
Write some extensions.
What do you think?
Yeah, definitely.
Write some extensions.
Yeah.
And if you're looking at the API, discuss the documentation.
I'm always happy to hear feedback.
And also if you find some difficulties or even just difficulties to get how to get started with TinyDB, I think that's worth of an issue on GitHub.
So other people can improve if you or other people can have an easier way to get started if you run into problems.
Yeah, just open an issue on GitHub and we can discuss things over there.
All right.
That sounds great.
So, Marcus, thanks so much for being on the show.
Yeah.
Thank you for having me.
Yeah.
Bye.
This has been another episode of Talk Python to Me.
Today's guest has been Marcus Siemens.
And this episode has been sponsored by Hired.
Thank you for supporting the show.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python to Me to get five or more offers with salary and equity presented right up front and a special listener signing bonus of $2,000.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my Write Pythonic code course at talkpython.fm/pythonic.
You can find the links from this episode at talkpython.fm/episodes slash show slash 80.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music.
You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.
I'll see you next time.
Open.
you