Is there an easy way to fetch db metadata from laravel?
I was looking to leverage Breezejs EntityManager, but I need to fetch the metadata on my DB and I was hoping I wouldn't have to define this twice.
Update
specifically, I'm looking to acquire schema metadata about entity structure
http://www.breezejs.com/documentation/metadata-by-hand
http://json-schema.org/examples.html
There's not direct method, but if you are curious and don't mind using DataMapper instead of ActiveRecord (switching from Eloquent to Doctrine) there's this repo that leverages support for BreezeJS generating the entity metadata from Doctrine ORM annotated models. They implemented an Employee Directory sample app, that can have laravel as one of the server variations.
I'm writing the metadata by hand for now (it's really not complicated), You can also write some code that can infer the models schema by parsing some query like 'DESCRIBE table_name' so you can stick with Eloquent.
EDIT: The answer to this question shows this DESCRIBE approach Can Eloquent models retrieve metadata on their rows?
Related
I am searching for a way for creating database by my models structure in Laravel 5.5.
I know many Orm Like Doctorin Or ActiveRecord has this feature and so some micro Orm such as redbean has this feature but I cannot find a good reference for this ability in eloquent ORM of Laravel and if there is any method has it migrations which alter my existing database according to my model changes?
I have been using Cakephp ver2.x and just started migrating to Cakephp v3.x. When I tried using the new ORM, I am baffled by basic concepts like repositories and table objects. What is the difference between repositories and table objects?
A repository can be anything while a table, as the name states, is just a table.
http://api.cakephp.org/3.0/class-Cake.ORM.Table.html
Represents a single database table.
Exposes methods for retrieving data out of it, and manages the associations this table has to other tables. Multiple instances of this class can be created for the same database table with different aliases, this allows you to address your database structure in a richer and more expressive way.
http://api.cakephp.org/3.0/class-Cake.Datasource.RepositoryInterface.html
Describes the methods that any class representing a data storage should comply with.
A data storage can be any kind of storage system, even one that doesn't know tables like a graph DB or document based system.
It is always simple to just check the API documentation and code for this kind of questions. The code is pretty well documented. Also the way this works becomes obvious then:
class Table implements RepositoryInterface, EventListenerInterface
Table implements the interface defined by RepositoryInterface.
I have two tables in DB (topic, topic_content):
what kind of entities i should create for symfony2?
I think, i should have something like this in my symfony structure (Entities/Topic.php, Entities/Topic_content.php) help me please..
Yes, you would create Topic and Topic Content. And likely also a User Entity (because user_id looks like a foreign key).
However, the idea in Symfony2 is to approach the application from the Model site instead of the database site. Quoting https://doctrine-orm.readthedocs.org/en/latest/tutorials/getting-started-database.html:
Development Workflows
When you Code First, you start with developing Objects and then map them onto your database. When you Model First, you are modelling your application using tools (for example UML) and generate database schema and PHP code from this model. When you have a Database First, you already have a database schema and generate the corresponding PHP code from it.
For database first, there is a generator that will derive objects based on your schema:
https://github.com/beberlei/DoctrineCodeGenerator
The recommended approach though is to have Doctrine generate the db schema from your Entities.
Quoting Getting Started - Generating the DB Schema
Doctrine has a Command-Line Interface that allows you to access the SchemaTool, a component that generates the required tables to work with the metadata.
It requires some setup, which is explained in the guide. Once you have that, you simply tell Doctrine to generate or update your schema, whenever your object structure changes.
What good is a repository pattern when you have an ORM?
Example. Suppose i have the following (fictional) tables:
Table: users
pk_user_id
fk_userrole_id
username
Table: userroles
fk_userrole_id
role
Now with an orm i could simply put this in a model file:
$user = ORM::load('users', $id);
Now $user is already my object, which could easily be lazy loaded:
(would be even nicer if things are automatically singular/pluralized)
foreach ( $user->userroles()->role as $role )
{
echo $role;
}
Now with the Repository pattern i'd had to create a repository for the Users and one for the Roles. The repository also needs all kinds of functions to retrieve data for me and to store it. Plus it needs to work with Entity models. So i have to create all of those too.
To me that looks like alot of stuff do... When i could simply get the data like i described above with an ORM. And i could store it just as easy:
ORM::store($user);
In this case it would not only store the user object to the database, but also any changes i made to the 'Roles' object aswell. So no need for any extra work like you need with the repository pattern...
So my question basically is, why would i want to use a repository pattern with an ORM? I've seen tutorials where to use that pattern (like with Doctrine). But it really just doesn't make any sense to me... Anyone any explanation for its use in combination with an ORM..??
The ORM is an implementation detail of the Repository. The ORM just makes it easy to access the db tables in an OOP friendly way. That's it.
The repository abstract persistence access, whatever storage it is. That is its purpose. The fact that you're using a db or xml files or an ORM doesn't matter. The Repository allows the rest of the application to ignore persistence details. This way, you can easily test the app via mocking or stubbing and you can change storages if it's needed. Today you might use MySql, tomorrow you'll want to use NoSql or Cloud Storage. Do that with an ORM!
Repositories deal with Domain/Business objects (from the app point of view), an ORM handles db objects. A business objects IS NOT a db object, first has behaviour, the second is a glorified DTO, it only holds data.
Edit
You might say that both repository and ORM abstract access to data, however the devil is in the details. The repository abstract the access to all storage concerns, while the ORM abstract access to a specific RDBMS
In a nutshell, Repository and ORM's have DIFFERENT purposes and as I've said above, the ORM is always an implementation detail of the repo.
You can also check this post about more details about the repository pattern.
ORM and repository pattern...depends on setup.
If you use your ORM entities as the domain layer, then please use no repositories.
If you have a separate domain model and you need to map from that model to ORM entities and so perform a save, then repositories are what you need.
More details you find here (but must be logged to linked-in). Also to understand the difference, check out the definition of the repository pattern.
Most people use classes that they call repositories, but aren't repositories at all, just query classes - this is how/where you should place your queries if you decided to go with the #1 option (see answer above). In this case make sure not to expose DbContext or ISession from that query class, nor to expose CUD-methods from there - remember, Query class!
The #2 option is a tough one. If you do a real repository, all the inputs and outputs on the repository interface will contain clear domain classes (and no database related object). It's forbidden to expose ORM mapped classes or ORM architecture related objects from there. There will be a Save method also. These repositories might also contain queries, but unlike query classes, these repos will do more - they will take your domain aggregate (collection and tree of entities) and save them to DB by mapping those classes to ORM classes and perform a save on ORM. This style (#2) does not needs to use ORM, the repository pattern was primarly made for ADO.NET (any kind of data access).
Anyhow these 2 options are the 2 extremes we can do. A lot of people use repositories with ORM, but they just add an extra layer of code without real function, the only real function there is the query class like behaviour.
Also I'd be careful when someone talks about UnitOfWork, especially with ORM. Almost every sample on the internet is a fail in terms of architecture. If you need UoW, why not use TransactionScope (just make sure you got a wrapper which uses other than Serializable transaction by default). In 99,9% you won't need to manage 2 sets of independent changes in data (so 2 sets of OuW), so TransactionScope will be a fine choce in .NET - for PHP i'd look for some open-session-view implementations...
Is it somehow possible to automatically generate a YAML schema file or models from an existing MySQL database?
I need to create models for Doctrine but writing the model classes manually seems extremely boring to me. I already have MySQL database with tables and all relations so it would help me if there is some way to generate Doctrine models from it.
If you are using doctrine 2:
http://www.doctrine-project.org/docs/orm/2.0/en/reference/tools.html#reverse-engineering
Yes, it is possible ;-)
For Doctrine 1.2, take a look at the Command Line Interface : amongst other utilities, you have the possibity to generate the YAML files from an existing database.
And, for Doctrine 2.0, you'll want to take a look at Reverse Engineering