Welcome Guest, Not a member yet? Register   Sign In
recommendations on ORM vs custom data mapper
#11

[eluser]WanWizard[/eluser]
Sorry, I was correcting it while you were replying. Wink

So yes, you define all relations in the model. There is a one-to-one mapping between models and tables.
The model extends the Datamapper class, and as such inherits all datamapper methods for navigating the table and the models related tables.

Datamapper also supports out of the box read and write validation rules. This means that no matter where in your code you read or write a record, validation is done only once, and consistent. No more custom checks in your controllers. (p.s. you can use read rules for example to unserialize() a stored serialized array to it can be presented to your code as an array. When you save it, the save validation rule can serialize() it again, completely transparent for your controller.

I can't comment on Doctrine. I used v1, and that was bulky and tearjerking slow. I hear v2 is better, but I don't have any comparison.

Datamapper is compatible with both Modular CI and Modular Extensions HMVC (it uses CI 2.x packages feature to extend the model search to modules).

http://datamapper.wanwizard.eu/pages/get...arted.html gives a nice overview of how things work...
#12

[eluser]Chillahan[/eluser]
Excellent, I really like the validation rules part and that is very nice about the serialization capability! Really saves a lot of work for storing array type data (I am thinking PayPal response codes off the top of my head, but a lot of situations could use that feature). Looking forward to trying it out, along with the two Modular solutions.
#13

[eluser]toopay[/eluser]
Hey Wanwizard, thats a great lib over there. I've try it, and its seriously twisted my assumption that there was no "real" ORM library on CI. Hahaha. I have a ported Sprig, Kohana stuff, as my CI project datamapper. Have you hear or tried Sprig?

Ah, anyway after this, no doubt i will give Datamapper ORM a shoot in my next project.
#14

[eluser]Nick_MyShuitings[/eluser]
Just a word to the wise, expect to spend a significantly larger amount of time trying to scale the app with an ORM... you will need more server juice, and the time savings you earn while coding thanks to ORM magic, you pay out in server juice and in scaling work.

I've just spent two months turning a Symfony project using Doctrine to all pure SQL so that they could get decent scaling (Symfony sucks terribly in its own right, but with Doctrine it was a nightmare)
#15

[eluser]toopay[/eluser]
Since Nick started talked about "Scalable-App", then someone(include Nick) maybe need to ask a simpe question : What (the heck) is scalability? And before (if we intend to disscuss it here) we go into the detail, we should dispel some of the falsehoods so common in contemporary web development literature by talking about what scalability isn't.

Scalability IS NOT raw speed. Performance and scalability are quite separate issues. You can easily have a high-performance system that doesn't scale, although the reverse is not often true-if system can scale, you can usually increase performance by scaling it out. Just because a system is blindingly fast for 1000 users and 1 GB of data, it's not scalable unless it can maintain that speed for 10 times the data with 10 times as many users.

Scalability IS ALSO NOT about using particular technology, including particular framework! In fact, scalability isn't about using any particular technology at all! So, wheter it is CI, Kohana, Symfony, Doctrine, FuelPHP or any "uh-oh" framework, a system built in any framework (even any languange) using any tools can be made to scale, altough the relative difficulty is an issue, of course.
#16

[eluser]WanWizard[/eluser]
[quote author="toopay" date="1305015082"]I have a ported Sprig, Kohana stuff, as my CI project datamapper. Have you hear or tried Sprig?[/quote]
Yes. I have been examining Kohana closely for another framework I'm working on. In the end, none of the available ORM solutions did fit our bill, so we wrote or own...
#17

[eluser]WanWizard[/eluser]
Whenever you use libraries to introduce some 'magic' to your application, you have to consider the pro's and con's for your particular situation.

If you're writing for yourself and the application needs raw speed because it's going to run on a low-budget Godaddy shared host, you'll make other decisions than when you're writing a large business application with a development team.
At my hourly rate, a days work roughly equals the cost of a dedicated quad-xeon server for a year. So if I introduce tools that greatly reduces the coding time, and makes maintenance easier, I have a business case.
#18

[eluser]toopay[/eluser]
[quote author="WanWizard" date="1305028798"]...So if I introduce tools that greatly reduces the coding time, and makes maintenance easier, I have a business case.[/quote]

I was think, just me that provoked by "Just a word to the wise" statement. Yes, of course, as developer, its worthed to build scalable-system, which has three simple characteristics :

1. The system can accomodate increased usage.
2. The system can accomodate an increased dataset.
3. The system is maintainable.

And above stuffs, as i said before, are quite separate issues also doesnt related with how much "juicy" our server (whether it is, like you said, low-budget Godaddy shared host, or even we have a huge pile of cash to burn through by buying Sun's current largest big iron like Sun Fire E25K, which supports up to 72 processors and can handle 576 GB of memory).
#19

[eluser]Nick_MyShuitings[/eluser]
[quote author="WanWizard" date="1305028798"]Whenever you use libraries to introduce some 'magic' to your application, you have to consider the pro's and con's for your particular situation.

If you're writing for yourself and the application needs raw speed because it's going to run on a low-budget Godaddy shared host, you'll make other decisions than when you're writing a large business application with a development team.
At my hourly rate, a days work roughly equals the cost of a dedicated quad-xeon server for a year. So if I introduce tools that greatly reduces the coding time, and makes maintenance easier, I have a business case.[/quote]

Exactly...

Its just a heads up (ie: word to the wise is a colloquialism for that), cuz lots of small developers I know personally, working on private pages, add in ORM's thinking it will save their lives, and then ask me why their app now benchmarks slower and is consuming the double of memory and sql calls. (I am PM at a 50 dev shop down in Argentina, and most of the guys do freelance) Just something to consider that not many pro-ORM devs usually bring up.

Can it save you time and frustration in development? oh completely. Is it often easier to bring a new person on? hell yeah. But do you inevitably take a performance hit that often increases nonlinearly as you scale the app (you have to start thinking about dehydrating the results, auto-loading only the first 1000 records etc etc etc).

I just pipe in cuz some new devs (and the forum has been filled to the brim with them lately), think of ORM and Active Record, like they are some magic box of unicorns and butterflies... without recognizing that you are just trusting a class and various functions to write and run your SQL for you.

Its a valid item to bring up, and I just choose to play devil's advocate on it. That said, DataMapper ORM is awesome code to study!, and I've used it on a few small projects just to test it out. Its what I would recommend if you've actually thought through the pros/cons of ORM usage with CI.
#20

[eluser]Nick_MyShuitings[/eluser]
@toopay,

You are correct in you default definition of scalability. My reference to the term was not in depth, nor did I seek to define it. When new programmers (the same ones who usually ask questions here that 5 minutes of google will resolve for you), think "scalability", they are thinking JMeter, seige, ab load tests, and they wonder why their results drop so drastically after adding the ORM or DB abstraction layer. They are thinking of the clause in their contract with the client that says some bullshit like XYX concurrent users with an average of XYZ seconds / page load.

You bring up the (IMO valid) argument that we would be better off calling that performance, and then proceed to define a (IMO better) definition of what scalability truly entails. I agree with you completely... but I've been programming for years now, and PM for almost as long... a lot of the guys in this forum can't even figure out a foreach... so I summarized my post in a way that experience programmers might find offensive/over simplified, in which case "sorry" Smile




Theme © iAndrew 2016 - Forum software by © MyBB