RapidDataMapper, a new Object-Relational-Mapper

[eluser]m4rw3r[/eluser]
The idea, at least this is how I have used RDM, is that I create a "method lib" which is the model.
This method lib contains a lot of the common operations (eg. get all artworks + their users + a cover image and make sure that it is active) which I use throughout my app, some of them perform queries and return the result, others return a query object which already has some data in it and to which I can add extra conditions (for edge cases) and eg. pagination.

I guess many used IgnitedRecord just as it was and wrote the lot of the queries in the model?
(Instead of adding new methods to the class inheriting from IgnitedRecord)
You can do that with RDM too, just use Db::find('classname') and then you have a query object you can manipulate.

So, to help with your error:

* Have you added the supplied MY_Loader.php?
* If you use a case sensitive system (Linux, Unix and the like (not mac OS X, strange enough), then make sure that the files are all lowercase (in app/data_model).
* Have you called either MY_Loader::initRDM() or $this->load->database() (after adding the MY_Loader) before you try to load anything RDM related (like the descriptor or the class in data_model)?
* A note about putting them in the same class: That will work as long as you *always* try to load the Track class before the descriptor.

PS. I've added a vote about which upcoming feature that is most important in the feature requests section in the RDM forum here: here.

Of course, if you have another suggestion, either post it here or in RDM forum's Feature Requests section.

[eluser]helmutbjorg[/eluser]
Ahhh... you hit it with 'make sure that the files are all lowercase'. I'll have a bit more of a play around with this tomorrow! Better get some work done right now.

[eluser]m4rw3r[/eluser]
Ok, good

I'm making that a warning then, it was written in the manual, but apparently it is buried beneath all the text .
(It will have a nice little header saying Warning before the paragraph, located in both sections dealing with CI )

[eluser]Jelmer[/eluser]
Hi m4rw3r,

I read the manual and love your approach. However, I'm already building 2 systems on top of a self-written ORM (probably very much inferior to yours) which was inspired in part by IgnitedRecord.
I'll probably switch to RapidDataMapper on my next project though as especially like the seperation of object & logic. I'll let you know my experiences when I've done some real stuff with it, but that won't be for another 2 months.

I might give it an early try if I get round to rewriting my own business's administration software - which I wrote in a hurry about a year ago when I needed it and still has a lot of db usage in the controllers. I'll let you know any experiences I have.

Regards & complements on the library!

Jelmer

[eluser]happydude[/eluser]
For me, I think the library packs a lot of punch but is kinda complicated and so will need some time for people to wrap their heads around.

[eluser]m4rw3r[/eluser]
I can agree that it might be a bit complicated at first.
I think it is mainly because you have to separate data, fetching logic, data description and data logic from each other. But because I have written it I might perceive it a bit differently.

Maybe I should try to write some quick start guide for CI? (and maybe provide an example app?)

[eluser]BrianDHall[/eluser]
I think it would be useful to have a little quick guide for CI at least, if not perhaps even a comparison between an existing ORM or two for those familiar with the basic concept. I would think perhaps IgnitedRecord itself, and perhaps Datamapper (DMZ) would be most useful.

As it is, in a brief 5-10 minute glance...I don't get it at all. It seems at first glance to take a lot of configuration, where now I'm use to copying a template model file, doing a search-replace on two terms, and making a database table and fields to go with the model. Takes about 5 minutes for one model/table, but with RDM it seems like there is much more to do and consider.

That might be an entirely inaccurate perception, but it's what I gather from a quick glance.

[eluser]happydude[/eluser]
A CI user_guide is definitely needed especially as you are trying to project a new development pattern which might take some time and effort getting used to (not to mention the slight deviation from our normal CI coding style).

Something tells me this is gonna be great though. Don't be dissapointed by the feedback just yet. I know you put a lot of work into this. Keep it up.

[eluser]m4rw3r[/eluser]
I've created the first part of two of the CI quickstart example:
Quick start example
Hope that shows a bit of a very simple configuration (two objects with a relation).
I will make the 2nd part later (= tomorrow or during the weekend), then I will also see if I can manage to port the code to IgnitedRecord and Datamapper (DMZ).

About the complexity, it seems complex because I had to cover everything in the same manual, and I decided to do a proper manual instead of a partially done job (well, it is still missing a few minor parts ).

RapidDataMapper has many features, therefore I have to cover them all. Some examples:

* Multi primary key support, even for relations.
* Remapping property and column names.
* Fully configurable values for all column/table/database/etc. names, no need to follow the naming conventions to the letter.
* New SQL builders which needs to be fully covered in the manual to be able to be used to their full potential (I just noticed that I may need to provide more examples and in detail description about how to use method-chaining with it).
* A lot of hooks.
* Completely decoupled data objects.

This makes it a bit harder to cover everything on a single A3 sheet

Usually you won't need them all, so you'd just use the ones you need (which is not much when you follow the naming conventions).

[eluser]happydude[/eluser]
Even if it doesnt cover A3 sheet, a reference guide showing how to quickly do configuration and utilize the most important functions will certainly come in handy.