I'm using Elasticsearch in my job, and I'm considering to connect with Elastic using FOSElasticaBunble as an intermediate abstraction layer.
But I have a doubt, reading the documentation, it seems that is possible to map types to Doctrine Entities, but it also seems that is required to combine Elasticsearch with another persistence layer, like a SQL DB, or MongoDB.
Is possible to use Doctrine Entities without any extra persistence layer aside from Elasticsearch?
Thanks for your attention.
Related
I have a PHP class which will have at least two inner-classes. I want to store the instances of this class into a mySQL database so that I can get all the data in a bulk instead of going through multiple number of tables.
So far, I have looked up serializing in PHP and storing them into a BLOB field of the database. However, with a object-class having inner-object-classes I am not sure how it will turn out or even is it possible at all? I could not find any helpful resources on this topic specifically.
What you are looking for is ORM, since serializing an object and storing in a database is almost never the solution. This is a nice thread for ORM benefits and their intricacies.
ORM allows you to map specific parts of an objects to difference fields, using multiple tables, all the way down to its most basic structures. It can handle one-to-many and many-to-many relationships, and perform operations on creation that give you more creative freedom and elegance in your code.
It is much faster than storing a serialized object because there are smaller more optimized queries performed.
The main advantages of ORM are:
Ability to use class inheritance
Built in validation for data structure security and efficiency
Prebuilt queries and methods on objects.
Disadvantages of ORM:
Boilerplate to set up.
More abstract than serializing an object.
I'm doing a simple MVC web app that is supposed to do different queries to a SQL database. I'm using Symfony 4 as a framework, mostly to take advantage of its routing features.
I know I could take advantage from Doctrine but I was wondering: if someone wants to use PDO instead of Doctrine is it possible to do so and how should it be implemented. Should I make a Database class with PDO that I could pass on to another class?
Yes, you are not required to use doctrine at all. You can just define your own service with required functionality.
But maybe you could use DBAL which is lower layer used by doctrine to handle creating queries (but doesn't include any ORM functionality).
there is a Repositories layer in my laravel project. I am a freshman about laravel. I can not fully understand the advantages of this layer. My colleagues tell me that it is purpose to lower the coupling of the codes. Obviously, it is true. But I also look forward to your comments.
Using repositories, we can create complicated query and isolated it behind a readable method name. The coupled used, when using eloquent, we must put the record name in eloquent query, but using repositories, we can hide the record name and put in the other place. So that is give some security reason too. Also we can use for grouped some entities for authoritative users. Repository allows abstraction from data provide engine.
This article can help you.
I am working on my HMVC project.
Right now I am using data mappers in order to move data between the models (domain objects) and a MySQL database. Each mapper receives a MySQL adapter as dependency. The injected adapter receives a PDO instance (a database connection) as dependency and runs sql queries on the database.
I also use a dependency injection container (Auryn).
I'd like to be able to simultaneously retrieve data from storages of different types (MySQL database, PostgreSQL database, XML feeds, etc).
Let's say, I want to retrieve User data from a PostgreSQL database (by using PDO data-access abstraction), to change it, and to save it into a MySQL database (by using mysqli data-access abstraction) on another server. So, there will be different data-access calls for the both database types.
My question is:
Should I create a different mapper for each storage type, like
UserMapperPgsql(PgsqlAdapter $adapter)
UserMapperMySql(MySqlAdapter $adapter)
, or should I create only one mapper with more adapters (one for each data type) as dependencies, like bellow?
UserMapper(PgsqlAdapter $adapter1, MySqlAdapter $adapter2, ...)
Thank you all for your suggestions!
What an odd project you have there.
Anyway. I would go with two separate mappers for separate storage mediums. Because trying to juggle those adapters inside a mapper might end up quite complicated.
That said, depending on how complicated the persistence logic actually ends up, you might benefit from looking up repositories as approach to streamline the API, that gets exposed to where your "application logic" is actually done.
I recently got a reply from a server company asking if we are using an ORM in our application which does all the work of sifting application side (like Rails) or if we write reams of SQL, embedded functions etc which would make the database server do the processing for you.
Can anyone explain what is meant by this. Our web application is made up of PHP scripts with functions that make calls to the database to retrieve rows of data, then PHP processes these rows as needed to return results to the user.
thanks
It basically makes your database tables appear like objects on the PHP side of your site so you can easily manipulate data.
For example if you have a User table, getting this user's name is as easy as doing: $myUser->getName();
adding a new user in your database would be:
$myUser = new User();
$myUser->setName('John Doe');
$myUser->save();
Of course this is pseudo code (actually PHP Symfony/Doctrine code), but it's a simple example so you get the point.
An ORM is an abstraction that is supposed to simplify working with a relational database in an object oriented language. It's basically a set of classes and methods that let you create, retrieve and update data without using SQL directly.
For instance instead of writing
$result=mysql_query('select * from sandwiches where color='green' and size='2');
you can use an interface like
$result=$sandwiches->get('color'=>'green',=>'size'=>'2');
and the ORM turns this into SQL and executes the query, taking care of joins, etc.
Popular PHP ORMs are Doctrine and Propel
If you don't know whether you're using one, than it's pretty unlikely that you are!
It is an Object Relational Mapping. See link to wikipedia below.
http://en.wikipedia.org/wiki/Object-relational_mapping
ORM is Object Relational Mapper. which maps the java objects to the database tables and lets you perform some database transactions thorough your code.
EX of ORM tools are like Hibernate, Ibatis ..
ORM is used for Mapping your database objects to your application objects.
In a simple application using ORM, you should have functions that gets/sets data from/to DB should return appropriate application object/objects.
ORM is a Wikipedia article on Object Relational mapping.
Object Relational Mapping is an easy way of mapping Database objects ( tables, views ... ) to classes/objects in OOPL.
Hibernate and NHibernate are a few examples of ORM. it does all the tedious task of handling and mapping result sets..