I was given this project to work on with absolutely no documentation or contact developer. I noticed in the database dump that they are storing what looks like PHP Namespaces for Eloquent models in a couple tables. For example an address table has a string column named "object_type" with the value always being "App\Entities\Client". I searched through the whole project for the PHP code that would use this value. Hopefully to give me insight to it's purpose. Not to my surprise, the project never uses this value. I just see it hard-coding these values upon insert into the DB.
My question is, is this some sort of Database and/or ORM modeling design practice? If so, could you explain how this could be used in a simple practical sense?
Maybe this was some concept the developer had and it never evolved. It's interesting idea but, the idea of joining through MySQL on a string conditional sounds like torture.
Sounds like Laravel polymorphic relationships:
Custom Polymorphic Types.
By default, Laravel will use the fully qualified class name to store the type of the related model.
And, yes, this is a valid modeling technique, though purists rightly argue this technique abuses normal form.
I am not sure what the developers where thinking.
But imagining we are in a forum with thread and replies to each thread. We maybe want to have a Favourites table where we can save replies and threads.
A way to do it would be to have a column in the favourites table called "object_type" (just to use the same term you have in your case) and then when we save an object into the database with eloquent we can use:
$favourite->object_type = get_class($thread); //or get_class($reply) in case we want a reply
$favourite->save();
This way will save the namespace of that class into the database. But laravel will recognise it when we get it from the database.
Hope this cold be helpful.
Related
I'm brand new to Symfony but am loving getting familiar with it (and many of the concepts behind it). MVC is pretty new to me in terms of the way I'm encountering it in Symfony.
My question is that if I have a simple array of commonly used data that I don't think necessarily belongs in a database table where should I store this. Is it an Entity? Should I store it in the Should I put it in the controller? Somewhere else?
I'm talking specifically about something like a US States array that I might use to power a dropdown. Right now I'm having to build an entity and store these in the database but would like to know if there is a better / preferred way to do this.
In my procedural days I would keep a file called "includes/arrays.php" and pull that when I needed one of these.
Thanks
If you want to use this data with other Entities, for example State would be connected to Adress object, I would stick with Entities, because it makes relations easier to implement and work with (I assume you using some kind of ORM e.g. Doctrine).
If you don't want to use this data with other entities, maybe you would like to hardcode them into all the templates somehow. http://symfony.com/doc/current/cookbook/templating/global_variables.html (I assumed you are using Twig).
A similar question was answered here:
Where to define static array related to an entity in symfony2 ?
It depends. I would opt by having that kind of data in the database. Suppose you in the future would have a back-office that update data.
Or you could use config files. For example, in yml format, arrays is easy to define.
Just like #foxtrot said, any data that is changeable should be stored in the database, just so you do not have to edit any code when a change occurs.
Firstly, I would create the Entity for the common data, and then I would use Fixtures to generate the entries in the database when you deploy your code.
This way, you allow later editing through either forms or phpMyAdmin, but you also get to write the default values into a PHP class so you don't have to manually enter all of them into the database.
See Symfony - DoctrineFixturesBundle
My question is more theoritical, as I am not quite sure if it is a better way to create a model in Laravel for each table on database, if yes, what would be the benefition of it?
I am using Laravel 4 Eloquent for the ORM.
Thanks
The basic answer is yes, you should have a model for each table.
But the long answer is "it depends". As for what "depends" is, it is something that comes with experience and also your design criteria. There is no 100% right answer that can be used everytime.
As a principle if you plan on accessing data from tables using Eloquent, then you generally need one eloquent model per table, so you can access the table using Eloquent functions.
As a principle you dont need a model if you never use Eloquent to access the data. i.e. perhaps you have a table that you only use the query builder on.
Is there a best practice in getting data from multiple database tables using Zend? I would like to know rather than end up wanting to refactor the code I write in the near future. I was reading the Zend documentation and it said that:
"You can not specify columns from a
JOINed tabled to be returned in a
row/rowset. Doing so will trigger a
PHP error. This was done to ensure
the integrity of the Zend_Db_Table is
retained. i.e. A Zend_Db_Table_Row
should only reference columns derived
from its parent table."
I assume I therefore need to use multiple models -- is that correct? If, for example, I want to get out all orders for a particular user id where the date is in between two dates what would I do?
I know that it would be possible to access the two different models from a controller and then combine their respective data in the action but I would not feel happy doing this since I have been reading survivethedeepend.com and it tells me that I shouldn't do this...
Where, why, and how? :)
Thanks!
If you're reading ZFSTDE, in chapter 9 (http://www.survivethedeepend.com/zendframeworkbook/en/1.0/implementing.the.domain.model.entries.and.authors) this problem is addressed by using a data mapper.
Also, you can join 2 tables, just be sure to first call on the select object the setIntegrityCheck(false) method. The docs say that a row should reference a parent table, doesn't mean it can not :)
Stop thinking about Zend_Db_Table as your "model".
You should write your own, rich, domain-centric model classes to sit between your controllers (and views), and your persistence logic (anything that uses Zend_Db/Zend_Db_Table/Zend_Db_Select) to load/store data from the database.
Sure, you can query several db tables at the same time. Take a look at the official ZF docs here http://framework.zend.com/manual/en/zend.db.select.html#zend.db.select.building.join
As for your example with getting all orders of a single user, table relationships are the answer http://framework.zend.com/manual/en/zend.db.table.relationships.html
lacking a fellow programmer to talk over the right approach for my problem, I decided to ask you. What is your preferred approach of mapping dictionary tables to a model in MVC paradigm, regardless of the MVC framework / environment you are using?
My problem is I have a couple of database tables that only serve as dictionaries and are related to other tables as foreign keys. A good example would be a table request having a status_id where statuses are kept in a separate status table.
Now, the latter table needs to be mapped to a model on the code-side of the application. I can either:
Define all the statuses as constants so they can be referenced in the code without poking those dreaded 'magic numbers' here and there. However, any change to the dictionary (database-side) would require a code modification.
Omit the `status` table at all and just define meaningful constant to be used across the code. Pros: one place to rule them all. Cons: all changes require diving into the code, now the database features 'magic numbers' not really being foreign keys
Try to translate statuses into the model automagically, adding a field like 'const_name' to the 'statuses' table and them creating the constants on the fly while loading the model. This one seems to have the most sense for me.
Would you mind to share your usual approach to this issue?
Best,
Bartek
If it's just going to be a set of constants that are contained in the database instead of code, you could have a static class load the status constants for everyone else to use. That way there's no duplication between db and code, and no magic numbers.
edit: since it's a static class, you could have it lazy load the constants. Don't hit the database until the first time someone asks for a status value.
I'd say if you going to change it often it's better to go with table. Otherwise static class is fine (for example no point having table to store sex, or list of states).
I have been reading a few questions previously asked and I haven't come across one that answers my question in "black and white" for me! So, apologies if this is repetitive. The question is probably similar to asking, "how long is a piece of string" but bear with me!
For a registernation system, I have a user model with functions such as:
add_user
delete_user
activate_user
The above user model deals with one table. The users table in the MySQL database.
You can guess what each function does but is this coarse enough? I mean should my model contain methods that are much broader such as:
add_record
delete_record
update_record
Where I pass in the table and a unique identifier of the record to delete, add or update?
I am using codeigniter, but I am interested in how things should be done in a pure MVC framework.
I apologise if this question is too picky.
Thanks all
I'm not sure what you mean by "coarse".
"should my model contain methods that are much broader such as: add_record, delete_record, update_record"
Absolutely not. Never. That defeats the purpose of having a model.
That kind of "general-purpose" stuff is what a database is for. The point of a model is to adapt the general database to your specific problem.
Your model should be specific to your problem.
"user model with functions such as: add_user, delete_user, activate_user" That's the point. Your model reflects your application, your problem domain, your solution.
Your model should be able to -- in effect -- stand alone. You should be able to wrap your model in a command-line app or a GUI app or a web page.
You can guess what each function does
but is this coarse enough. I mean
should my model contain methods that
are much broader such as:
* add_record
* delete_record
* update_record
Where I pass in the table and a unique
identifier of the record to delete,
add or update?
If you have a need to get only the information of a user doesn't necessarily make use an entire record, then it is just right for you to have *_user functions, but include it only in your user model.
If you have a need to get an entire records instead of just the user, then it is also just right for you to have *_record functions, but put it in your record model - NOT in your user model.
The thing to remember here is to not include all of those functions in just one model. Simply put, your user and is the same as a record.