We're growing into something new. Read More

Posts tagged with orm

Guestback Brochure 12p

Brochure pour la présentation des avantages et fonctionnalités de la solution Guestback. Guestback est un logiciel de gestion de reputation hôtelière qui centralise et analyse les avis clients.

Guestback Affiche A5

Affiche A5 pour le Salon Equiphotel 2012. Guestback est un web service de réputation en ligne pour les hôtels.

Guestback Flyer

Flyer 3 volets pour Guestback, logiciel en ligne de réputation pour les hôtels


1. Collect hotel guests' feedback: this tool centralizes all the sources where guests talk about you and send you alerts, so that you can react immediately. 2. Analyze your hotel reputation: interactive graphs are displayed on your dashboard + real time feedback. 3. Competition reputation watch: determine your strong and weak points compared to the competition + permit you adapt and improve your communication. 4. Feedback to convince and attract new clients: several tools powered by Guestback enable to emphasize the best comments on the hotel's social media platforms.


No More Repositories

The Repository Pattern is a popular implementation pattern for encapsulating data operations, but it's not always the best idea to implement it. In this article I explain why there are drawbacks to using the Repository Pattern, and what alternatives exist.


Some Doctrine 2 Best Practices

Building on my last blog post on profiling Doctrine 2 I have put together another post outlining some best practices for its use. In Summary: 1. Always write a DQL statement for querying your object models 2. Beware of lazy loading when querying entities with associations 3. Use array hydration for read only actions 4. By default Doctrine will fetch all of the properties for a given entity 5. Use prepared statements 6. Be aware of what Doctrine is up to Check out the blog post for a couple of code examples and some explanation. If anyone else has anything to add, or any comments I would love to hear them.


OO and the DB - serialization vs ORM

Hi all, I wanted to get some opinions on how people store their site/application data when object-orientation is used. In recent work I've done both - coded a ORM style layer to map tables to object properties, and also go a bare-minimal DB field approach and simply store my objects as serialized data. I quite liked the serialization method. If you make sure to keep everything serialized except data that would otherwise be an index or a key (which may create some doubling up of data), it seems to be more flexible and "application friendly", to an extent. At least IMO. But is there something I'm overlooking? Downsides I'm not considering? Assuming the language you're working in has simple serialization abilities, it seems pretty easy to implement.


ActiveRecord Rails Associations through object_type and object_id

In my database, I have a table called 'likes' with a field for object_type and object_id. Basically, object_type will either be a post or a comment (defined by an integer for which kind) and object_id is the id in the database for that type. How to I go about relating these data sets together? That way I can use ActiveRecords associations. So, basically like this. posts id comments id likes object_type int object_id int


Combining Models in a Fuel-based application

I've decided to go with the Fuel framework for a fairly large/complex app, and would like to get some feedback on the model architecture I went with. This turned out to be a really long article, but I beg of you to bear with me while I provide the background info needed to get to my point ;) The app is, among other things, a CRM, and as such contains multiple "People" models, like Employee, Client, User, and many models that have addresses. In an early incarnation of this app I was going about it the traditional way, simply adding those fields to each model they belong to, along with the helper methods that went along with that data, like get_name() and address_formatted(), etc. I found myself repeating a lot of code, so I came up with a new architecture: I isolated the Person and Address fields into their own models, so that people models like Client "have one" Person, and that Person "has one" Address. My codebase at first seemed brilliantly simple, but I quickly ran into trouble when it came time to display the fields and then validate them. Fuel has a really cool class called Fieldset that makes dealing with form generation and the validation of those forms pretty damn easy. That is, if you're not bending the rules like I am. Take the following example of the set_form_fields() method that the Fieldset class uses to collect fields for form display and validation: // In my Model_Client class // $_properties contains field definitions for all fields in the 'clients' table public static function set_form_fields($form, $instance = null) { foreach (static::$_properties as $prop => $settings) { $name = is_int($prop) ? $settings : $prop; $label = isset($settings['label']) ? $settings['label'] : Inflector::humanize($name); $attributes = is_array($settings) ? $settings : array(); $rules = isset($settings['rules']) ? $settings['rules'] : array(); $form->add($name, $label, $attributes, $rules); } $instance and $form->repopulate($instance); } Raw Code » This works great for the fields directly in the Client model, but won't display the fields in that client's Person and that Person's Address. So what about taking the fields from the related Models like so: (this would be inside the set_form_fields() method) Model_Person::set_form_fields($form, isset($instance->person) ? $instance->person : null); Raw Code » This works, but would fail if any field names in Model_Person conflicted with those in Model_Client. This is just about a deal breaker for me, but let's say this could be avoided: The form markup would generate just fine, and when the form gets POSTed back to the server, I could grab all the fields and validate them as simply as: $form = Fieldset::forge('client')->add_model('Model_Client')->repopulate(); $form->validation()->run(); Raw Code » And if I have my relationships configured properly, saving the data would look like this: $fields = $form->validation()->validated(); $client = Model_Client::forge($fields); $client->person = Model_Person::forge($fields); $client->person->address = Model_Address::forge($fields); $client->save(); Raw Code » And I believe that's it. Editing existing records would take pretty much the same form. To be honest, this question started out as "This architecture didn't work--any suggestions?", but as often happens to me during the writing of a long call for help, I've made some slight changes that allowed it to work. So, my fellow Forrst people, do you have any suggestions on ways I could improve this setup? Or am I crazy for going this route, and you have a better way of solving this problem?


To ORM or not to ORM

That is the question. So before I charge head first into the fiery pits of Mount SQL I'm keen to hear peoples opinions on ORMs and, to be more precise, if I should take that avenue. My main concerns are really the extra bloat an ORM may produce. I'm also worried about complex queries, and having to switch between both raw queries and using an ORM in different parts of my application. The other option suggested to me is to create my own core model with CRUD methods for the more simple things and stick with using raw. Personally I like using raw, there isn't THAT much extra time spent writing a query and at least I know I have complete control over it. It would be nice to hear some other opinions though. Thanks! Update: I'd just like to share a link to a really good article about ORMs that I found quite useful.


Questions about starting project with Doctrine ORM

I'm working on a smaller project that I'm using/learning Limonade. I need to have some persistant storage mechanism and I've always been interested in ORMs particularly Doctrine but never had the chance to learn one. Does anybody have any recommendations? I'm going through the getting started portion of Doctrine now. I have experience with CodeIgniter and the ActiveRecord class they implement. I did a search for "ActiveRecord PHP" and found this PHPActiveRecord. My only reason for looking at solutions other than Doctrine is it seems a little heavy for what I need. Thanks for your suggestions! *Also if I were to use Doctrine, is it a good practice to flush the database interactions in an object's destructor method? I was thinking it might be, but this is all new to me.