If you could have any API you wanted to access data from Python, what would it look like?
What would make it Pythonic? This week, you'll hear about Pony ORM. Pony is a Python ORM with
beautiful query syntax that lets you write your database queries using Python generators and
Lambdas. Join me in a conversation with one of Pony ORM's founders, Alexei Milošković.
This is Talk Python to Me, episode 87, recorded November 3rd, 2016.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter
where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm
and follow the show on Twitter via at Talk Python.
This episode has been sponsored by Rollbar and GoCD. Thank them both for supporting the podcast
by checking out what they're offering during their segments.
Alexei, welcome to Talk Python.
Hi, Michael. Thank you.
Yeah, it's great to have you here. Thanks for coming. I'm super excited to talk about your
ORM and that you built this, what I'm saying might be the most Pythonic ORM yet, which because
of the really cool query syntax that you use and a couple of other highly Pythonic techniques
and I'm very impressed with it. But before we get into the details of Pony ORM, let's talk
about your story. How'd you get into programming in Python?
Well, I was always interested in programming, actually. When I was a teenager, I had a Sinclair
ZX Spectrum computer, played computer games and started to program BASIC. And actually,
it was the reason for me to get a master's degree in computer science later. I was programming
while studying in the university, but what I really liked was computer networks. So after
graduating, I started to work as a network engineer in an IT department of an airline company. And at
that time, it was 2001 and 2002, airline agencies had to use dedicated list lines for connecting
to airline database system. And I figured that using internet for that would be like 100% cheaper.
And then I got that crazy idea of developing a client server solution, which works over internet.
So I developed a prototype and it consisted of an app written in Delphi and a Linux server. And
then I presented it to the airline management team. And they were impressed and offered me
to form a development team. So from that point in time, I continued as a developer.
Yeah, that's think of the times back when you had to have a leased line or back when you had
BBSs, you had to dial up to get online. Like it's just such a different world, right? But
that's really cool to help that company like emerge out of that world.
Right. So now you cannot imagine that not using internet, right?
Exactly.
Yeah. So and then several years later, I started to work for another company. It was a fintech startup.
It was a New York based company and they outsourced the development to St. Petersburg, Russia,
this city where I'm originally from. And I was developing the backend in C++ and Java. And when
the business took off, they decided to form a team, a development team in New York. And they
invited me for this role. So I moved to New York and formed a development team there. And it was
building software for seven years there. And during that time, actually, my friend, Alexander
Kozlovsky, we studied together in the university. And he was really, really interested in databases.
And he was actually a senior lecturer. So he taught people databases. And he feared that most
people actually don't get relational algebra, you know, and there should be a better way to
build software. He suggested an idea to build a web framework. And I love the idea because working
for a financial company, I saw that it is a very fast environment. And I actually missed a tool like Delphia,
rapid application development tool. And I thought that if I would have one, I would use one. And this is how we started to work on Pony. And it was a weekend project, actually, initially.
And it was a template engine. It was routing. It was ORM. And then we found that probably we shouldn't do all those things because it's too much.
Yeah.
And by that time, by that time, Circle Alchemy appeared. Actually, we started the same year, 2006. It was the first year when we started to work together. And actually, by that time, Alexander already tried to build a mapper. He tried in C++ in Delphi. And Python was a choice which he came to understanding that it should be a dynamic language.
Yeah, I'm sure it was much harder in C++ to pull something like this off, especially with the really rich language level query syntax. Like, I'm not really sure how that works in C++.
Right. And then we started to work together on this. And he told that it was a SQL object, such a mapper. And in one of email lists, he suggested that why not to use generator syntax for writing queries. And I love the idea, too, because it was natural syntax for queries.
It's a completely natural syntax. Like, I think of generator expressions and list comprehensions as kind of like in-memory database operations, just working on your objects, obviously not indexed or anything like that. So if you're going to do that in your Python code, but somehow project that down into the database, that's perfect, I think.
Yeah, exactly. And what we liked as well, that it is so natural for someone who just starts working with Python, that you don't need to actually learn another language such as SQL.
Yeah, I think you probably could get away with just being able to read but not write SQL with Pony.
Yeah.
Yeah. Or SQLAlchemy or some of the other ORMs, right? Like, if you can understand the debug output, you may be okay. Who knows? It depends on how complex I suppose it gets. But that's a cool goal anyway.
Exactly. And I worked with people who actually can program different languages, but it's hard for them to understand SQL pretty well.
And that's why we decided that if we could provide such a tool, it will be very helpful.
And I could see how it can speed up making prototypes.
And, you know, when you build a prototype, you never know if it will be an application later and how it will evolve.
Yeah, absolutely. That means... I wonder how many applications there are in production in the world that were just supposed to be prototypes.
I bet it's a really high percentage.
Yeah, I agree. You need to have a tool which allows you to start quickly.
And then when you actually evolve with this application evolves, you want it to allow you to build this as complex as you want.
Well, yeah. And also the ability to recreate the project quickly rather than manage some huge data access layer with some kind of ORM that's really nice and clean.
Like Pony ORM is a really good thing to have so you can say, no, no, this is a prototype.
We're going to start again. But it only takes like this morning and then we'll have it back to where it is.
But proper. Something like that, right?
That's cool.
An app that created using a simple tool can reach a point where the further development is too difficult or even impossible.
And having reached this borderline of complexity, it's often no time actually to start from scratch.
Yeah, it's usually you're already down that path and it's too late.
How interesting.
Okay, so let's talk about Pony ORM a bit.
So Pony ORM is a data access layer.
It's an ORM, object relational mapper.
How would you describe it if somebody asked you what is Pony ORM?
Well, it is an advanced object relational mapper and it provides a very easy interface.
And even a newbie can start working with this.
That is one thing I was struck with when I was working with it is I was almost thinking like, well, how do I connect back this object to the entities?
Like, where do I create the entity base class from?
And how do I, you know, why don't I have to call add to insert objects?
And why don't I have to call commit to commit them?
And all of those answers are because you're using some really interesting Pythonic concepts that sort of simplify a couple of the steps that you might have found in other ORMs.
Right.
And Pony, it's a small horse, right?
It's small, smart, and powerful.
So we believe that these features we put into our mapper.
I think so, too.
I think it's really, it is really nice.
And I'm looking forward to using it properly on some projects now that I know a little bit more about it.
So I want to ask you what's Pythonic about it.
But I think maybe the way to uncover the various Pythonic elements is to actually work through an example.
But before we get to that, let me ask you this other question.
So there's these two styles or two design patterns that typically are in play at ORMs.
And that's whether or not the ORM acts as an active record where you sort of work with individual elements.
So like Ruby on Rails or I think the Django ORM is like this.
Or it's a unit of work, which is like SQLAlchemy, where you create a bunch of objects and make some changes, inserts, updates, deletes, and so on.
And when you're finally ready, you commit that unit of work and it applies all of those.
Which style is Pony?
Yeah, absolutely.
There are two basic patterns.
And with active record, you have an object which represents a line in the database.
And the thing is that if you select the same object twice using active record, you will have two instances of the same object in the memory.
And it is a huge problem because now you have two objects which are actually the same.
And when you start to change one object.
And then change another one, you can have lost updates.
And another thing that you need to always remember to call safe on each object.
Yeah, exactly.
And you don't really do that with unit of work.
You just kind of work with your data.
And when you're ready, you commit it, right?
Every time you read a record from the database, we first check in the identity map if there is such a record already loaded into the memory.
And this allows us to return an object from the cache from the memory instead of querying the database.
Yeah, so that's cool in that it gives you better performance because you're not round-tripping to the database as often.
But it's also maybe even more important that it means if you somehow get the same object twice, it's still the same object in memory, right?
Exactly.
So it allows us to avoid excessive database calls.
And at the same time, we always work with the same copy of the object.
And another option that it provides us with is to manage transactions.
So we can see when the scope of a function or a context manager was left.
And at this point, we can commit all the changes to the database.
It is very convenient.
Yeah, that's very convenient.
I love your use of context managers in this project.
So maybe that's a good place to jump into talking about the code.
And we have to be a little careful on audio format talking about code.
But maybe we could just kind of roughly walk through some of the steps involved.
And we could talk about the Pythonic concepts as we get to them.
Okay.
So obviously, yeah.
So obviously, to get started, you have to import Pony, right?
So there's a number of things in there that you got to work with.
So pip install Pony, import Pony, and so on.
And then you create a database.
So a database is just an object, right?
But this database has a couple of features that go on to be super important.
Like on that object, you have a base class.
And all of your entities have to derive from it, right?
Exactly.
So when you create a database, at this point, it is just an object.
And later, when you create entities, you inherit it from db.entity, which is an attribute.
And it is abstract class, which tells that it is an entity which is connected to this database.
And having such pattern, actually, you can create several databases.
You can simultaneously work with more than one database.
Right.
Maybe you have like a core database that has your important stuff and then an analytics database for tracking how people are using your app.
Something like that, right?
Yeah.
It's very often used this way.
Yeah.
And then you create, like you said, you create this class that derives from db.entity.
What does it look like to define the columns?
The main difference of Pony from other mappers is that we work in terms of entities.
So in SQLAlchemy, you work with relations.
And here with Pony, we hire the level of abstraction and work in terms of entities, in terms of objects.
And we don't create columns.
We create attributes of the object.
Because this way, we figure that it is easier for a human being to think in terms of objects, not relations.
Yeah.
And probably Python as well, right?
We're used to working with hierarchical collections of objects anyway.
Yeah.
And then you create attributes.
And we provide a very concise way of declaring such entities.
Because from the first day of developing Pony, we actually had three goals.
We wanted this mapper would be easy to use.
It means having PyTonic API.
It should be very performant.
So high performance is the goal.
And the third is safety and reliability.
So we would like to avoid SQL injections and make it reliable.
Yeah.
You do some really nice stuff to avoid SQL injection attacks.
And I'll talk about those later as well.
Yeah.
So when you declare entities, it is as short as possible.
You just write the attribute name and then the type of the attribute.
So it could be a required attribute or optional.
Another two options is you can have a primary key or a relationship to another entity.
And then in creating the attribute, you specify the type of the attribute and some additional options like unique or auto generator.
When you want to have a sequence creating a new object, sometimes you want ID to be automatically generated.
Right.
And of course, you have default values as well for like created dates and things like that, right?
Right.
So we have API reference.
And there are about like probably 15 options that you can specify for attribute.
And you asked about columns.
You can also specify the name of the column.
If you would like to give a specific name to the database column or if you have a database already created and you would like to map these entities to the existing tables.
So you can specify the table name and the column name declaring the entity.
Yeah, that's excellent.
So let me try to give people a really quick example here.
So you've on your GitHub, you've got a nice example called eStore.
And you have relationships between like customers and products and stuff in a shopping cart and so on.
So you obviously have a customer class and a product class and so on.
But just to like talk about the simplicity.
So for a cart item, the whole thing is you have a cart item class that drives from db.entity.
It has a quantity, which is a required column, which is an integer.
And then you have a customer, which is a required customer object.
Just literally parentheses the class name, not even in quotes, just actually the Python class object.
And product required of product.
So here's an object that has two relationships back to customer and product.
And it's like the simplest thing you can imagine, right?
Right.
In order to make it even simpler, you can take a look at the diagram at our entity relationship diagram editor, which represents this database schema.
So you can visually see this.
Right.
So for people who are listening, if they want to find it and they don't want to go in the show notes, it's editor.ponyorm.com slash user slash pony slash E capital S store.
Of course, I'll link to that.
Yeah, that's really cool.
And you guys have this wonderful online designer that shows you the relationships that lets you model and rearrange them.
Even get the what would be the generated SQL, the generated Python classes, and so on.
Definitely, I want to come back and talk about this online editor because it looks really special.
So, yeah.
So very cool.
We create these entities and the relationships are really super simple to set up.
So that's wonderful.
And then another thing that you chose to do in your API is make the ID something that is optional.
Right.
Oftentimes, you don't have a natural primary key.
Yeah.
And in this case, you just create attributes that you want to have in the entity.
And if you don't declare primary key, pony will add it automatically.
And it will be integer type with sequence.
Yeah, the auto-incrementing primary key.
Exactly.
Yeah.
Yeah, that's perfect.
So then you go through the standard stuff.
You bind to a database connection and a database type.
What types of databases are supported?
So currently, we support four major databases, which are SQLite, Postgres, MySQL, and Oracle.
And currently, we are working on adding Microsoft SQL Server.
So we had users who asked us about it, and we actually added this type of database.
But the thing is that recently, we added a JSON type support.
So you can work with the database JSON type and make queries to those JSON types.
And this part, we didn't add to Microsoft Server yet.
But after we will add the JSON support, I think we will include it into the release, and we'll support five databases.
Oh, that sounds great.
I mean, those are basically the major ones.
Are there any that people are asking for that are asking for commonly that are missing?
Only a Microsoft SQL Server was something we were asking about.
Yeah, it seems to me like those five rounded out.
Tell me more about this JSON thing.
Is this something that is JSON stored in like Postgres or SQLite, or is it something else?
Right.
So we used the native database JSON type.
So it is JSON B, binary JSON for progress and for MySQL.
For Oracle, it is, I believe it is Club.
And for SQLite, normally it is stored as text by default.
But you always can install a module, which is called JSON 1.
And this way, your queries to SQLite will be faster.
Okay, so there's a module that I can extend.
I see.
That I can extend SQLite so that it can understand the internals of that JSON document so I could possibly query by some attribute deep down inside it.
Recently, we have added native JSON data type support.
And this way, we can actually combine NoSQL database with a relational database.
So it's like having best of two worlds.
In a relational database, you can declare an attribute of JSON type.
And in this attribute, you can keep the data structure, which can vary.
Yeah, this is really cool.
So basically, you have regular columns, but you can also have hierarchical columns that are stored as JSON, more or less.
That's right.
Yeah, it does very much seem like here's a MongoDB type thing going on as part of that table.
Exactly.
And you can actually do queries to the internals of this JSON structure, which is described in our documentation.
Yeah, yeah, that's cool.
Can you add indexes to the internals of that data structure?
I think not yet.
It's down to whether the database is supported, I'm sure.
Probably if the database supports that, you can...
Actually, it is just a native JSON type for the database.
If a database supports index, you can add an index.
Right.
Okay, that makes sense.
So it's really a question of, does MySQL support indexes on embedded JSON types, which I actually don't know the answer to.
So that's cool, though.
We have users who use this feature in production already.
Nice.
So yeah, speaking of production, can you speak of some of the notable deployments of PonyRM?
I mean, I know the vast majority of no visibility into, but...
Yeah, some of them asked us not share their details because they have PR departments that they need to approve it with.
And for those who we can share, I put testimonials to our site.
Oh, yeah, excellent.
I see at the bottom, there's a whole bunch of testimonials and people can come check them out.
I'm sure not everybody has permission to divulge whether they're, you know, speak on behalf of their company, but that's very cool.
So when I was working on the new version of the site, I sent this request to all our users.
And actually, those people paid for the license because initially we had Pony released under dual license.
So it was AGPL and it was commercial license.
And then we figured that AGPL actually doesn't really work with the community.
People don't like AGPL at all.
And although we were selling licenses, we decided that we probably need to change our model and we just need to release Pony under Apache 2 license.
And think about the possibility to monetize our editor because it really can be a tool which allows people to develop applications faster.
And we use the same model as GitHub.
So if you would like to share your data schema with everybody, make it public, you can use it for free.
And if you would like to have a private data schema, then we'll ask to pay some money.
Yeah, I think that's a great model.
And we'll definitely talk about it.
That's at editor.ponyorm.com.
Yeah, it's very cool.
This portion of Talk Python to Me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
Ah, relying on users to report errors, digging through log files, trying to debug issues, or a million alerts just flooding your inbox and ruining your day.
With Rollbar's full stack error monitoring, you'll get the context, insights, and control that you need to find and fix bugs faster.
It's easy to install.
You can start tracking production errors and deployments in eight minutes or even less.
Rollbar works with all the major languages and frameworks, including the Python ones, such as Django, Flask, Pyramid, as well as Ruby, JavaScript, Node, iOS, and Android.
You can integrate Rollbar into your existing workflow, send error alerts to Slack or HipChat, or even automatically create issues in Jira, Pivotal Tracker, and a whole bunch more.
Rollbar has put together a special offer for Talk Python to Me listeners.
Visit rollbar.com slash talkpython to me, sign up, and get the bootstrap plan free for 90 days.
That's 300,000 errors tracked all for free.
But hey, just between you and me, I really hope you don't encounter that many errors.
Loved by developers at awesome companies like Heroku, Twilio, Kayak, Instacart, Zendesk, Twitch, and more.
Give Rollbar a try today.
Go to rollbar.com slash talkpython to me.
Let's focus for a moment on what I think are really getting to the Pythonic concepts.
What we talked about so far with the way you work with Pony is it's very nice, but it's not super unique.
And it's just like a nicer version of what I feel like the other ones are doing.
But then you get to things like working with context managers and decorators and all sorts of really nice stuff.
Tell us, how do we like insert data?
Or how do I get like a database connection and commit it and go through like that whole set of steps there?
Well, when you bind entities to the database, the next step, you need to generate mapping.
And this way we just connect objects in the program entities to the database tables.
And then you can start working with the database.
You can select entity objects or create new objects.
And all that interconnection should be done within the database session because it is a transaction, right?
Right, this whole unit of work thing, right?
Yeah, unit of work, exactly.
So you need to either create a function and decorate it with DB session.
Or you need to use the context manager and work with the database within this context manager.
Yeah, so let's focus on that for a sec because I think that's great.
So if I want to make a bunch of CRUD operations, inserts, updates, deletes, and so on, one way to do that is write a function that changes the data, creates objects, it updates existing ones.
And all I have to do is put a decorator at DB session on that method.
And it will handle both the positive outcome and the negative outcome.
So if that method runs to completion without errors, without exceptions, it will commit the transaction.
But if for some reason there's an exception in there, it will roll back the transaction just by virtue of having the decorator, right?
Exactly.
So when you wrap your code, which works with entities with DB session, it actually does the following.
When you start working with the database, it doesn't start the transaction from the first moment.
Because if it is just read, you don't need to open the transaction.
You can read from the database without opening it.
And when you start to change, the new transaction is created.
And then when you leave this scope, if no exception happened, then Pony automatically will commit the changes to the database.
If an exception happened, then it will be rolled back.
And you can specify parameters to this decorator.
For example, if you would like to retry several times, you can do that specifying parameters to the decorator.
That might be helpful when you have more than one process working with the same table with the same row.
And Pony has a concept of optimistic checking.
So this way we avoid a situation when you can lose updates.
When Pony saves something in the database, it actually adds checks that the attribute values keep the same.
Because when you work with objects, Pony tracks which objects you read and which objects you write.
So if you, for example, in your code, read an attribute and then do something and save this object into the database,
Pony will make sure that attributes that you read keep the same.
Because if it don't, it means that some other process changed the database.
And in this case, it cannot be saved in the database.
Yeah, this is very common in the sort of disconnected unit of work styles of ORMs.
But I really like this model.
I mean, the alternative is pessimistic concurrency, which is to say, lock the database.
Nobody can do a thing until we're done with this whole part, right?
And everybody get in line.
And I'm going to do a bunch of changes.
And then you can go make your queries or other operations on the database and not see inconsistent data.
And that's great.
But it also kills concurrency and all sorts of things.
With this model, the optimistic concurrency, it's like, well, probably nobody changed this record also.
So it'll just do all the work.
And then it'll say more or less something to the effect of, update person with ID this where the name is the old name.
Set the name to the new name.
Something like that, right?
So the goal of Pony is provide consistent API and ability to work with the database,
even for people who don't know much about transactions and lost updates.
So we would like Pony to provide such an easy way to work with the data reliably.
Yeah.
And I think the retrying thing is really interesting.
A really interesting addition there.
Sometimes you don't want to make an entire method, basically a transaction in a sense.
So you can use another Pythonic concept of context managers, right?
So you can just say with DB session, do you work in that little suite?
And then when you're out of there, it follows the same rules.
No exceptions, commit.
Exception, rollback, right?
Right.
And at the same time, this concept of optimistic checking, it works by default in Pony.
But if you need to log the database, do for update query, you can do that too.
There's a method for entity has a method for update, and a query has such a method for update.
So this way you can log the database if you need.
Right.
Okay.
Very cool.
So the next thing, once you have data in the database, of course,
you want to write a query.
And this is where, this is what got my attention in Pony in the first place, is the way that
I would, like, say, do a query on, like, a bunch of people we inserted to the database
at the person class would be to write a generator that would do the in-memory query.
So you'd say something like, select P for P in person if P dot age is greater than 20.
And, like, that's literally what you write.
Yeah?
Yeah.
You write this generator and pass it as an argument to the select function.
And what Pony does?
And what Pony does, it gets the bytecode of the generator.
It decompiles it in order to extract the abstract syntax tree.
And then it translates this abstract syntax tree into SQL.
And made a presentation on the EuroPython in 2014.
And it is available on YouTube where I explain the whole process, how we actually do this translation.
Because before, a lot of people actually asking if this translation is fast enough.
And I should tell that the whole thing works really fast.
And the thing is that you need to translate each generator only once.
In the whole program, you need to translate the generator bytecode only once.
And then it will be cached.
And the result of the translation to SQL will be cached as well.
And after that, we just have the SQL query where we just put parameters and send it to the database.
That is really awesome.
I'm definitely going to link to your 2014 talk.
You could also do, like, projections.
So, like, in a generator expression, I could say p.name, p.age for da-da-da-da.
You support basically doing projections at the database level in the same manner, right?
Right.
So, basically, you don't even need to think in terms of tables.
You just work with objects.
And you can select a whole object or you can select a specific attribute.
Or you can even do aggregation.
So, you select a tuple.
For example, you select p.name.
And then, for example, if we have some...
Let me give you this example.
For example, you work with a customer.
And this customer has some orders which has the attribute total amount.
So, you can do aggregation and return from this query a tuple where you have the customer name and then aggregated amount of his or her orders.
That's really cool.
Do you have some good examples of that on your docs?
Yeah.
Okay.
I'll be sure to link to them.
Yeah.
Send me the link.
And finally, if for some reason this syntax doesn't work for you, you're just like, you know, I just need to write a SQL query and just have something happen.
You can do that as well.
And so, you could just go to your entity which represents the table and just say select by SQL and give it some kind of SQL statement.
You can write a row SQL, but what is more interesting is that you can insert a row parts of SQL query into a generator.
You know, we have such a function, row SQL.
And, for example, there is a function in the database which is not supported in Python, for example.
Then you can insert this piece of row SQL into a declarative query written in the form of a generator.
That is really awesome.
And I also like how you automatically capture in your SQL text local variables as names.
So, like, if I had X defined locally, in my SQL statement, I could say $X and you would translate that to a parameter, right?
Yeah.
And one second, let me send you the link for a row SQL.
Oh, yeah.
That's really amazing.
So, you can just say raw SQL as part of either a Lambda or a generator expression and it just, it's going to execute on the database, right?
Exactly.
So, if you insert this part of a row SQL into the translated query.
Now, one thing that's interesting is you have both Lambda expressions and generator expressions.
Right.
When do I use, and I can pass those as the select clause.
So, when do I use which?
If you would like to get an object as the result, you can use Lambda or generator.
So, they will actually be translated into the same SQL query.
But if you would like to aggregate the aggregation or return just a tuple of attribute names, then in this case, you use a generator because it allows you to put any expression in the beginning of the generator.
Right.
And it will be returned as a list of such tuples, for example.
Yeah.
I really love that aspect of Pony.
That's super cool.
So, let's talk about parameters because it's super important for the safety of your app that you don't write just straight up raw SQL with concatenated strings, right?
Like, if anybody has a doubt, just Google little Bobby tables.
So, the parameters here are really great.
Like, tell us about that.
Pony allows you to avoid SQL injections absolutely because all the parameters that we pass into the SQL query, they are passed as database parameters.
So, this way, there is no way to get a SQL injection.
And also, Pony allows you to pass not only parameters but expressions as well.
So, you can find that part described in the documentation.
When you pass the parameter, you can specify the whole expression inside the generator query.
That's really great that you can pass expressions as well.
I think there's always tradeoffs when you use something, some kind of ORM versus just writing raw SQL entirely.
I would, personally, the safety from SQL injection attacks, the fact that you might forget to use a parameter somewhere, almost alone makes it worth using ORMs.
Not to mention all the cool benefits of everything else.
So, yeah, I think it's really great that you have all these levels of safety, especially for web apps.
Yeah.
So, let's talk about the team.
You talked about your co-founder just a bit, but maybe mention him again.
And how many people are working on the project now?
Currently, we have four people.
So, Alexander Kozlovsky is my co-founder.
And we started to work with him together.
And at some point, I decided to leave my job and concentrate on Pony full-time.
Congratulations on that.
That's awesome.
Yeah, thank you.
Although, we found another project later.
So, currently, we work on Pony.
We have four people.
We have two more developers.
So, one of them works on backend and another on frontend.
So, his role is to help us build our editor.
We have big plans on that.
And currently, we actually, yeah, we work on the editor as well.
Nice.
Yeah.
So, tell us where are you going?
What features are you adding?
Currently, you can use the editor in order to create entity relationship diagram.
And then get either a Python classes or SQL create table statements.
And this is actually used a lot by users who actually don't know anything about Pony.
And when I write them that, do you use Pony?
Why not you just start opening the tab with Python classes?
They actually, often, they don't know a thing about Pony.
And when they discover this possibility, they love this feature and start using Pony as well.
Yeah, that's great.
Yeah.
So, let's talk about your editor a little bit.
So, I really like it.
Like I said, editor.ponyorm.com.
And the idea is it's basically a database diagram development tool, right?
So, you can see your tables.
You can see the relationships and so on, which all that is really cool.
And I can, like, add a new entity.
And it gives you a whole nice designer.
It shows you a bunch of stuff that maybe you didn't realize was something that you could model,
like the volatility of attributes or things like this.
But then once you get your model built together, you can actually go and say, show me the Python code.
Yeah, show me the Python code.
For the various databases and so on, you know, you can create this.
So, you can create a tool that you can create a tool that allows them to do the whole cycle of development.
So, when they can create a diagram.
So, when they can create a diagram and then get the Python code and work on the project.
And when they need to change something, they can just change it in the editor and get their migration applied to the database.
And keep those, the log of the changes in the editor.
Nice.
Yeah, okay.
So, that's really neat.
That brings us to migrations a little bit.
What's the story of migrations there?
This point is the feature which is most asked.
And at this point, we are working on migrations and we developed the prototype.
And it works great.
But what we would like to add, an ability to write comments inside the migration file the same way as in Django.
So, when you just write operations like add attribute or add relationship, I believe that it will be released within the following month.
But it is not that fast.
The development of migrations took longer than we initially suggested.
Yeah, it seems like it might take a while.
It's a non-trivial thing.
That's right.
But we are very close to the release at this point.
Nice.
Yeah, what are you doing after you get the migrations done?
Some time ago, we started to work on a project which is called Fine Art Biblio.
So, it is a Miami-based company.
And the goal is to provide Wikipedia for modern art.
I formed a team for this project.
And from day one, we started to use Pony.
It was actually our goal to find a company where we can use Pony in order to build the back end and see how we can make it better.
And when we were working on this project, we found that when we need to build a front end, we actually need to have the same models as the front end.
And we thought, why not to provide a way to have the same identity map, the same models as the front end.
And this way was Pony.js.
This way, Pony.js appeared.
So, Pony.js is a don to Pony, which is not released yet.
Why, I will tell a little bit later.
And this way, you can get the objects which are extracted in the back end.
You can have the same graph of connected objects at the front end and work with them in JavaScript.
Nice.
So, I can just basically expose my models from my back end as some kind of service that Pony.js can consume.
And then they're like replicated over?
Or how does that work?
When you extracted objects from the database, then you call the to.json method.
And it returns a set of objects which will be sent to the front end.
And the front end, we have a library, Pony.js, which puts it into an identity map and allows you to work with objects the same way you do it on the back end.
So, you can traverse attributes.
You can traverse relationships.
You can create new objects and send them back to the back end.
That's cool.
And for allowing this, for making this work, we created a layer of permissions and security.
So, it is also a declarative language which allows you to tell which operations are allowed.
Create, delete, update, or modify.
But when we were working on this project, we found that Facebook released GraphQL.
And we thought that probably it is the same thing that we are working on.
And we decided actually to try GraphQL.
And by this time, we had one more team member joined to our company.
And he developed GraphQL server.
And now we have actually three ways to work with the front end.
And after we release migrations, we believe that integration with the front end actually will be our major focus.
Yeah, you have your back end stuff pretty much dialed in.
So, extending that seems like a great idea.
This portion of Talk Python to Me is brought to you by GoCD from ThoughtWorks.
GoCD is the on-premise, open-source, continuous delivery server.
With GoCD's comprehensive pipeline and model, you can model complex workflows for multiple teams with ease.
And GoCD's value stream map lets you track changes from commit to deployment at a glance.
GoCD's real power is in the visibility it provides over your end-to-end workflow.
You get complete control of and visibility into your deployments across multiple teams.
Say goodbye to release day panic and hello to consistent, predictable deliveries.
Commercial support and enterprise add-ons, including disaster recovery, are available.
To learn more about GoCD, visit talkpython.fm/gocd for a free download.
That's talkpython.fm/gocd.
Check them out.
It helps support the show.
So, your docs are in Python 2.
I want to encourage you to write them in Python 3 and tell a story.
So, when people were looking at the adoption of Python 3, maybe a year ago or something like this,
and I think around that time, Django switched its documentation to Python 3.
They didn't do anything else.
They just said, look, Python 3 here.
This is the way you do it in Python 3.
And, oh, it also supports Python 2.
And the usage of Python 3 on PyPI went up significantly, like some number of percent total because of that.
But my real question is, does it support Python 3 as well as Python 2?
What's the story around on the various versions?
Yes, it does.
Nice.
Yeah.
So, all the stuff that I've done with it worked totally fine, and I was playing with it in Python 3.
So, that's great.
So, I'm really fascinated by people working on successful open source projects that have businesses around them.
And so, can you talk just really briefly about your project and the editor and the business model around it?
We think that the editor could be helpful for startup companies and for companies which develop new projects.
Those people who we were talking to who would like to use Pony in their projects, we found that what they like in Pony is simplicity and that Pony allows them to save resources.
So, they can start fast.
They don't need dedicated backend engineer sometimes.
And they just can easily return to the project which was developed like a year ago and do some changes without actually looking through the manuals.
Because the query language is really simple and it allows to maintain projects with less resources.
We think that for such people, for such companies, having an editor would help them to build prototypes and to work on applications even faster.
Especially if they would be able to work on the same data schema together.
And this is one of the features we would like to add to our editor.
So, the idea is that it is software as a service.
And if you would like to create a diagram and share it with everyone, it is free.
And if you would like to keep it as a closed source diagram, then there is some price for this.
And it depends on how many diagrams you would like to have.
Sure.
You know, one thing I think is really interesting about this.
You talk about people getting started more quickly and helping new companies or new applications get up to speed.
You have an explore section here.
So, I can drop in and find things like you've got a corporate directory already modeled.
And you've got an e-commerce store modeled and a university modeled and things like that.
So, if I know that there's something in your explore area.
Some of these are created by you guys, but many of them are by others.
And I'm like, well, how exactly would I model this?
Let me just look and see what other people have done.
Right?
I could go and just start from there, right?
And copy that.
Yeah, exactly.
And maybe at some point, we will add an ability to deploy the schema to a cloud database and write logic right there.
Yeah, that's pretty interesting.
Is there a way to take and reverse the thing?
So, I've got the diagram which generates my Python.
Could I take my code that I've been working on for six months after starting with one of these and throw the Python in and get the diagram out?
Probably we should add that.
But at this point, the most people are asking about a reflection tool for the database.
So, when you can just get the log of the database, create table statements, and create a diagram based on that.
Yeah, that makes sense.
Which, I guess, is probably the most important one is you want to be exactly like your database and give me the Python classes to make that happen, right?
Right.
So, someone would like to work using Pony with a database, and they just don't want to create those classes or a diagram.
Yeah, if you've got a thousand tables, you probably don't want to spend time trying to model them again.
Just push the button and have that pop out, right?
That's cool.
All right.
Well, we're getting near the end of the show.
This has been really interesting.
I'm really fascinated, especially with the Pythonic style of Pony.
So, thanks for telling us all about it and giving us the backstory.
It's great.
Thank you, Michael, for having me.
Yeah, you bet.
So, before I let you go, though, I have a couple of questions for you.
There's over 90,000 packages on PyPI these days.
And you probably come across some that not everybody knows about.
What one would you like to recommend to audience?
Well, I love Flask.
Flask is definitely nice and great for building apps, especially for building APIs, I think.
Right.
We use it in our projects, and it's simple, and you can develop very fast using Flask.
So, that's why I like it.
All right.
Flask.
Great recommendation.
And if you're going to write some Python code, what editor do you open up?
PyCharm.
Nice.
Yeah.
A lot of the PyCharm team is based in St. Petersburg, along with you.
Yeah.
So, do you know some of the guys there?
Yeah, I do.
Actually, we met with them, and we were asking them to add support for Pony.
And we agree that when enough people will be asking about it, they will start working on
this.
All right.
Well, maybe this show will give them a little nudge, huh?
That's cool.
Any final call to actions for everyone?
Like, how do they get started with Pony and your project?
Please go to pony.rm.com and read the documentation.
Try Pony and give us feedback.
We have a Telegram group where people can discuss Pony features and ask questions or stack overflow.
And please give us some feedback so that we can make Pony even better.
All right, Alexei.
Thank you so much for being on the show.
It's been fun to talk to you.
Thank you, Michael.
It was a pleasure.
Yeah.
Bye.
This has been another episode of Talk Python to Me.
Today's guest has been Alexei Milashkovic.
And this episode has been sponsored by Rollbar and GoCD.
Thank you both for supporting the show.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have
gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at
rollbar.com slash Talk Python to Me.
GoCD is the on-premise, open-source, continuous delivery server.
Want to improve your deployment workflow but keep your code and builds in-house?
Check out GoCD at talkpython.fm/gocd and take control over your process.
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.
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.
with my voice.
There's no norm that I can feel within.
Haven't been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.
Developers, Developers, Developers, Developers, Developers, Developers, Developers, Developers,
.
you