Thread

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?)

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.

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. 😊

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).

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.

Yup, I’m considering doing a cheat sheet for RDM, which explains the commonly used stuff
(most likely the methods and their parameters, I’ve strived for them to be logical).

I think mainly what is needed is just a way to very quickly and easily get started with the library and begin using it to do something useful, even if it uses only a tiny percentage of what RDM is capable of. DMZ uses an example of a very simple auth system, as a for instance.

If RDM is able to use existing database structures with some configuration, then that’s a big ‘selling point’ - in my pre-DMZ project I’m stuck with a hybrid system where I use DMZ for new functions and leave the original functionality in standard CI AR.

Perhaps there is some existing CI application, like perhaps one of the CMSs or auth library, or maybe just something really basic like hooking up RDM to use CI Session tables as objects and manipulate them directly via RDM. Basically show how RDM can be bolted into an existing system without requiring database restructuring (and thus program refactoring).

I think just something easy to get you in to using it for something useful is the single most important thing, as learning by clear example and then tweaking the sample is what I personally find the easiest way to learn.

The big reason most people don’t use ORM is complexity and learning curve, so anything you do to drop the barrier to getting started then logically more people will get started.

@m4rw3r: congrats for your new contrib’ !

I just took a look at your docs… and if I’m not mistaken:

* bulk updates and delete are possible on models ?
* and it can be propagated to related objects too ?

Just wondering if you also plan to migrate your MPTREE library using RDM ?

It’s a pitty that multi-DBMS support isn’t yet implemented but… hey, your orm library is quite young finally 😉

Best,

Benco

@all:

The second part of two of the quick start guide is done: http://rapiddatamapper.com/forum/viewtopic.php?f=6&t=3&p=5#p2.

It is very simple, and shows how little code is needed to interact with the database

@BrianDHall:

Yes, that is one of the strengths of RDM, the ability to change all the defaults of the mappers (without losing performance too!) to whatever you like. You can also create new descriptors which contain your own default class -> singular -> table conversion algorithms (the same goes for columns, relations and primary keys).

About creating a sample app; I’ve made a simple (and dirty) quick start app here: http://rapiddatamapper.com/forum/viewtopic.php?f=6&t=3.

But I’m also going to resume my involvement in Ionize, and we’ll see if I use RDM there (probably a gradual change, I need to restructure the template parser usage too).

@ben_co:

Bulk updates and delete are not really implemented, but if an object is changed, then all the related objects will also be saved if they have been modified (depends on the relation type).
So it is not really a fully working bulk update.
(But I have planned a bit on making it, when I’ve decided how to implement the Unit of Work handler (I think I can try to create some nice algorithm for creating the least number of queries (for update/insert), but some help with that would be nice 😉 )

Deletes of related objects will be supported (and I will probably also see to it that updates always propagates to the related objects), with the Db_Descriptor->setOnDeleteAction method (it is implemented, but not the logic behind it).

About multi DBMS-support, it is supported, the problem is that RDM only has one driver: MySQL 😛

I started trying to intergrate RDM into an existing system I have and I think I found a bug.

I’m using prefixes and when I don’t set a table or anything in the data_model descriptor I get an following error that reads in part (I changed the database name to DBNAME):

‘RapidDataMapper: ERROR: 1146: Table ‘DBNAME.users’ doesn’t exist

Which I thought to fix by adding the prefix by using $this->setTable(‘pref_users’) but then I got an error that read in part:

‘RapidDataMapper: ERROR: 1146: Table ‘DBNAME.pref_pref_users’

[I just edited the paragraph below because I first thought it was a problem within the find function instead of a difference between the find & update]
I believe that the first error is caused by a Db::find() statement and that the second is caused by Db::save() - and as such my guess is that the prefix is added when using update but isn’t added when using find.

I’m trying to find it myself and will edit this post when I find the code, but you probably know precisely where to look.

[EDIT:]Solution
It took me a while but I did learn a lot from figuring out how it works and what I had to change. I found the problem in the Db_MapperQuery_Part_Properties class.
Line 21 says:

$this->addPart(new Db_CodeBuilder_Property('from', array($db->protectIdentifiers($desc->getTable()).' AS '.$db->protectIdentifiers($desc->getSingular()))));

Which doesn’t add the db table prefix. I’ve changed it to:

$this->addPart(new Db_CodeBuilder_Property('from', array($db->protectIdentifiers($db->prefix($desc->getTable())).' AS '.$db->protectIdentifiers($desc->getSingular()))));

Which seems to have solved this.

And a question. Maybe I’ve missed it in the manual but I can’t figure out how to do a “WHERE `columnname` IS NULL”.

Is it possible to have a “IS NULL” or “IS NOT NULL” condition?

[EDIT]
And one last thing before I call it a night. When I use the following code:

$domain = Db::find('domain', $id);
$users = Db::related($domain, 'domain_users')->get();

Fatal error: Call to undefined method Db_Compiled_domain_userMapper::populateFindQuery() in /application/libraries/Db.php on line 556

Which is correct as far as I can see, is it a bug or did I configure something wrong?

Thanks for the fix! Sorry I wasn’t faster, had some other things to do last weekend (well, yesterday and the day before that).
Apparently I forgot some things when I created the Db_MapperQuery class (before it was a part of the Db_Mapper, which created custom Db_Query_Select, but that was worse in both flexibility (you can actually have behaviours add methods to the Db_MapperQuery objects) and performance).

I have fixed the faulty method call (in Db::related) in the new RDM version: 0.5.1
I also added methods for dealing with IS NULL and IS NOT NULL (something I forgot to add when I modded the behaviour of where() to accept condition fragments).

New RapidDataMapper Version: 0.5.1

Fetch the new version from RapidDataMapper Downloads!

Thanks for the update!

I’m however running into another problem now. In CI the MY_Loader.php calls on line 158:

Db::attachLogger(array(‘MY_Loader’, ‘db_log_message’));

But you seem to have removed the attachLogger function and it’s corresponding array $loggers from the DB.php which makes for the following error:

Fatal error: Call to undefined method Db::attachLogger() in /application/libraries/MY_Loader.php on line 158

I fixed it for the time being by commenting out the line in MY_Loader

That has been updated, you are only using an old variant of MY_Loader.php.

I will make upgrade instructions next time… (did not think I needed to, but apparently I did)  :red:

Oops, I forgot that was included in the package - I should have checked.

It works like a charm, I’m actually enjoying rewriting my CRM/Invoice/Administration system. 😉