Home

Welcome to the Mythix ORM wiki

Getting started

Here you will not only find documentation for the Mythix ORM API, but also articles (in the "Pages" section) that explain in detail the inner workings of Mythix ORM.

To start with, we highly recommend reading the following articles:

1. Query Engine
2. Associations

These should give you a basic idea on how to work with Mythix ORM.

After you have read these articles and understand what you are working with, take a look at the API documentation to understand what you have available to you, and how you can use it.

What Mythix ORM is (and is not)

Mythix ORM was designed and created to replace all the terrible other options that currently exist for Node. I mean, have you ever looked at the source code for some of the other popular ORM libraries out there? It is the stuff of nightmares!

I was tired of daily having to deal with malarky spewed by the other ORM libraries and their very poorly designed interfaces, their bloat, and their difficulty to setup and use (to say it mildly).

Though I firmly believe ORMs are--in nature--a poor and terrible fix for the plethora if crap us developers must go through daily trying to work with outdated and non-standard databases, they do still have their place in our world (until the database "situation" is resolved). So, while ORMs are still needed, why not at least use the best one available?

Meet Mythix ORM. It was designed from the ground-up to replace all other existing ORMs, forever. As part of the design, a few key decisions were made to make Mythix ORM a far better solution than the other "solutions" out there.

Let's go over those key design decisions real quick so we are all on the same page:

1. Mythix ORM will never be bloated. It has a specific purpose, and it will stick to that purpose. It is an abstraction layer between different database types. It doesn't intend or pretend to be anything else. Mythix ORM is bare bones, just what you need, and nothing more. It is the intent and hope of the authors that Mythix ORM will grow a thriving community, and it was a deliberate design decision that the community would build extra libraries to add features to Mythix ORM. The motto over here in Mythix land is "take what you need, and nothing more".
2. Mythix ORM is very extensible. Nearly every part of Mythix ORM can be overloaded, hijacked, or replaced entirely. Again, the intent is that the community will provide many cool features through extra libraries that add to Mythix ORM's feature set. It was also the intent of the authors who designed Mythix ORM to have it so developers could work with it the way they like to, without any of the mandates, and the "world should work this way" shenanigans. Mythix ORM is very powerful, and absolutely will allow you to shoot yourself in the foot--if you, as the developer, decide that is what you want to do.
3. The primary author of this library--Wyatt Greenway--doesn't like the "black box" mentality. Encapsulation is absolutely a must for clean and stable code, but "black box"? Never. For this reason Mythix ORM was designed with no private variables, and nearly every method exists on a class, with the deliberate intent that methods could (and should) be overloaded to provide extra functionality. Please do overload methods, and change the behavior of Mythix ORM to fit your team needs. But please be a good citizen, and read and understand what you are doing and why before you do it. Mythix ORM will naturally change its interfaces over time (with appropriate versioning applied to each release), and it is up to the downstream developers to update and manage their custom code.
4. Mythix ORM deliberately tries to abstract everything it can away from the database. Because of this, you will often find cases where you might need to do things differently then you are used to, or you might find some of our design decisions a little strange. ORMs are supposed to be an abstraction layer, so when I see other ORMs suggesting database specific code in their documentation it makes me shudder. Obviously there are times where this can not be avoided, and Mythix ORM does its best to handle these cases in an abstract way. However, there may be times where you just need to make a direct query to do something with your database, or use a custom literal, and that is okay. One area that you will immediately notice this abstraction is the field types. There is a shockingly small number of field types available in Mythix ORM, and this is deliberate. Mythix ORM will never supply database specific field types... if you need those, you can use literals, or you can define your own field types to suit your needs. The situation also isn't as bad as you might initially think. Take the INTEGER type for example. It is designed such that it can receive as an optional parameter the "number of bytes" needed to store a certain integer type--and then it is up to the specific connection you are using to decide how to implement said type. For example, Mythix ORM does not supply the MySQL specific types like TINYINT, SMALLINT, or MEDIUMINT. Instead, you always simply use INTEGER, and specify the number of bytes you need, and the MySQL connection will take care of the rest for you. Field types are just one example. Mythix ORM will abstract away everything it can by deliberate design.
5. Mythix ORM and its API were deliberately designed to be as simple as possible, with all the complexity required tucked neatly away in the modular connection drivers. Deliberate intent and lots of thinking went into making the interface simple, yet flexible and powerful. For these reasons Mythix ORM is broken into many pieces, so the developer can pick and choose only what they want. Mythix ORM was also deliberately designed so that it could be run inside a browser. "Why in the heck would I ever do that?" I hear you asking. Well, Mythix ORM has more to offer than just being a layer between databases. Its model system, and especially its query system, are slick, and useful outside the context of server-only. I hope to one day see "browser based" connections that allow developers to use the same powerful query interface built into Mythix ORM inside the browser. I mean, how cool would it be to use the powerful built in query-engine inside the browser? Maybe to generate GraphQL? Or a custom query interface over HTTP? Let's think big and outside the box.
6. SQL/NoSQL, who cares? From the ground up Mythix ORM was designed to support SQL and NoSQL (or even completely custom) databases. Connection drivers are painless to create, and the horizon is the limit. Currently Mythix ORM officially only has drivers for PostgreSQL and SQLite, but in the future it plans (and intends) to support every database on the planet, including file storage systems, and in-memory databases. If you don't see the database driver you are looking for, be patient, or better yet, help out! Before Mythix ORM is considered "done" it will have drivers for MySQL, Microsoft SQL, Mongo, Snowflake, SOLR, ElasticSearch, and many more.

Now let's take a little moment to discuss what Mythix ORM is not:

1. Mythix ORM is not bloated, and it never intends to be. We will continue with the modular architecture, giving developers the ability to choose what they want to include (and what they don't want to include). This also means that you, as the developer, need to pay a little more attention. You can't just install Mythix ORM and away you go. You also need to select which database driver you need, and install it manually beside Mythix ORM.
2. Mythix ORM is not "magical". In fact, we despise "magic" and won't have any of it. Everything must be clearly defined, and must visibly exist somewhere. Mythix ORM will not automatically create fields for you (i.e. created_at and updated_at), not even for relationships, polymorphic or not. The tedium you may come across was also considered, and accounted for. For example, if you want everyone of your models to have a created_at, and updated_at field, then simply create a base model that all of your other models inherit from, and on the base model itself you can define these "common" fields. The intent is to give the developer full control, while keeping all "magic" off the table.
3. Mythix ORM is not opinionated. It is actually the opposite. It is the intent of the authors that developers will use and modify this library exactly how they want to. We don't make glaring statements like "We won't include a toSQL method because no one should ever use such a thing!", or silly statements like "You should do things our way... because we obviously know best". Ha! Whatever! No, we don't know what is best, and we openly admit it. You, the developer, know what is best, and we support you. Do want you want to do, and do it well. Make your mommy proud! Just remember that when you shoot yourself in the foot, it is your foot, not ours.
4. Mythix ORM is not a swiss-army knife, batteries included, does everything under the sun type of library. It can do everything you need it to do however, and it does so in a modular, community supported way. If you want extra features, build them, or rely on what the community builds. Mythix ORM will deliberately always remain small, slim, sleek, and do exactly what it does the best it can, and nothing more.
5. We--the authoring team of Mythix ORM--do not always know what is best. We know this, and are humble enough to admit it. This is one of the prime reasons behind deciding to lean heavily on the community for support and extra features. When the community builds something that thousands of people are using regularly, then--and only then--will we consider adding it as a core feature to Mythix ORM. In short, we want the community to drive the bus. We will take a back seat and see where it goes, cheering and supporting the entire trip.

Mythix certifications

Mythix, as a community of libraries, has a certification program. We will certify third party libraries, and we recommend that you select certified libraries first. Why are we doing this? Part of the mission Mythix has is to reengage engineers to actually be engineers, instead of StackOverflow monkeys. We can not even begin to tell you how many times we have wept over the stank we have seen in open source libraries. We would prefer that Mythix, as a community, not be involved in the stank of the rest of the world.

For this reason we will maintain a list of "certified" libraries, whose code bases have been groomed for cleanliness and correctness. We will also maintain a "black list" of libraries that use Mythix technologies, but that have severe stank. We welcome all developers, and hope to build a thriving community around Mythix technologies... but be warned, if you are a poor engineer and poop out poor code, then your project might end up on a blacklist...

The above statements are intended to inspire all developers to become better versions of themselves. Our world is a train wreck of smelly broken code (that is often popular, unfortunately). Mythix hopes to take a hand in changing the landscape, by lifting developers up and supporting good engineers, helping them standout as pillars of hope against the background noise.

We won't be rude, unfair, or bigoted. We will be precise, keen-eyed, care about what we build, and drive engineers to be better engineers. We like the word "accountable", and would like to hold ourselves and our community of engineers to a higher standard. Let's build great things together, not smelly things that everyone hates. Our certification and blacklists will simply serve as a means to try and prod engineers to do a better job, and to aspire to a higher standard.