Welcome Guest, Not a member yet? Register   Sign In
RapidDataMapper, a new Object-Relational-Mapper

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




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

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


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


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

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 Tongue

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):
Quote:'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:
Quote:'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:Confusedave() - 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.

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?

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();
I get the following error:
Quote: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:
Quote: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:
Quote: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. Wink

Theme © iAndrew 2016 - Forum software by © MyBB