Download the PHP package trismegiste/dokudoki without Composer

On this page you can find all versions of the php package trismegiste/dokudoki. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package dokudoki

DokudokiBundle Build Status

What

It's a bundle based on Yuurei, a micro database layer with automatic mapping.

This bundle adds multiple features aside from the original mapping of Yuurei : 3 others mapping systems (full magic, aliasing and mix of both), form components to handle MongoDate and uploaded files, DataCollector for WebProfiler and of course, a lot of services injected in the DiC of symfony2.

I try to make an agnostic DBAL which helps you in the process to build an app regardless the model is finished or not. So there is also migration tools.

How

Use Composer like any other PHP package :

For Symfony 2.3

Legacy for Symfony 2.x

Why

Because, like the cake, "ODM is a lie". Turning MongoDB into an ORM-like abstraction is the worst thing you can do against a NoSQL database.

I'm fed up by both CRUD antipattern and anemic model produced by ORM and code generators. In the end, you realized that you must model your classes for the ORM and not for the business. I wanted to restore the Domain Driven Development philosophy developed in Symfony2 and ruined by Doctrine2.

Guidances

So, you make a model divided in few parts without circular reference, and you store it. It's like serialization but in MongoDB.

All non static properties are stored in a way you can query easily with the powerfull (but very strange I admit) language of MongoDB.

See the PHPUnit tests for examples.

Four modes of working

This DBAL has 4 stages, regarding the completion of the model classes.

The trick is you can migrate between these stages when you develop your app and, for example, don't need to start over after a dirty prototype. You even can generate a model from the data you had stored into collections when you don't have one.

See Examples of using this dbal in PHPUnit Tests

Black Magic is black

If you have no model and a lot of forms to design, start with the "BlackMagic" stage. If an anemic model is enough for you, don't create one. It is full of magic methods, magic mapping and magic documents, it's like working with mockup.

But be warned : it is for prototyping and your database can turn back against you if you are not careful. That's what I call "Form Driven Development".

See full example in unit test

Serialization could be enough

This is the original mapping system from Yuurei. If you have a lot of nearly complete model classes and don't want configure anything, use the "Invocation" stage. Only magic mapping and strict typing between objects and documents.

But if you need to make complex queries or map-reduce, it can be very dirty. This stage is usefull for RESTful app without GUI.

See full example in unit test

White Magic is for Lawful Good

If you have a good model and the time to carefully alias classes in the database, use the "WhiteMagic" stage. There is automapping but without surprise, your model cannot turn into chaos. Any non-aliased class will generate an exception.

See full example in unit test

Hoodoo child

If you need to evolve the model above, you can use "Hoodoo" stage, a "WhiteMagic" stage mixed with some magic from "BlackMagic" stage. There is a safety net to prevent some "real" classes to become "fake" classes. This lowers the rate of WTF per minutes and you choose the level of magic.

About performance

I have not fully tested this dbal but the hydration is the slowest part of this layer. For example, one document with 100 entities (think about a customer, with his addresses, past orders with products etc...) takes about 100 ms to be stored on a standard dual-core desktop without APC.

It is not very efficient but when you seek high performance, you can forget about ORM, ODM and so on.

FAQ

Is Symfony2 mandatory ?

No, the DBAL can work in standalone mode. Anyway you miss a lot of features with forms and black magic stage. The full framework itself is not mandatory, only some components. And almost all unit tests don't need any symfony component. For example, you could easily make a provider for silex and pimple.

What are the requirements ?

How to map properties ?

All object's properties are stored. You have only one thing to do : The root classes must implement the Persistable interface (there is a trait for implementing this interface). You don't need to extend any particuliar class, therefore you can follow the DDD without constraint.

What is a "root class" ?

It is a class stored in the collection, which contains the MongoId in the key '_id'. All other agregated objects in this class don't need to implement Persistable, they are recursively stored.

How can I remove some transient properties ?

You can't. But you can have a transient class with the interface Skippable. Use Decorator pattern or a State Pattern. Your model can do that.

Can I make some cleaning before persistence ?

Like serialization, you can implement Cleanable with 2 methods : wakeup and sleep

How can I query for listing ?

Use the MongoCollection, you can't be more efficient than this low level layer

How can I store pictures or PDF ?

Use a MongoBinData in your model, it is stored as is

Can I use something else than MongoId for primary key ?

No

What about MongoDate ?

Any DateTime are converted into MongoDate and vice versa.

I see you're using mongo types in your classes model, what about abstraction ?

Seriously, have you ever switch an app to another database ?

Is there any lazy loading or proxy classes for DBRef ?

Fly, you fools

Why this silly name ?

Well, I'm not good at finding names, that's why I tend to keep the most ridiculous than the most serious. It stands for Docu(ment) + doki to recall "dokidoki" (loosely means "excitment", sounds like heartbeats) in japanese. This one, I'm pretty sure it is unique ^_^


All versions of dokudoki with dependencies

PHP Build Version
Package Version
Requires php Version >=5.5
ext-mongo Version >=1.5.0
trismegiste/yuurei Version 2.3.*
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package trismegiste/dokudoki contains the following files

Loading the files please wait ....