CMS Made Simple Forums

Hello everyone

I'm thinking about adding ORM features into cmsmadesimple and i had two possibility : rewrite the wheel or use a existing ORM (like Doctrine)

Let's go for the wheels ! ... I've already written last year a very small ORM and it was a great adventure ... but i would try something bigger like CmsMadeSimple > Doctrine > Adodb > Mysql

But the more i searched, the more it seems that it would be impossible ... Adodb and Doctrine doing the same (database Abstraction Layer) so it's only possible to have :

cmsms > adodb > mysql
cmsms > doctrine > mysql (??? i don't know if it's would be possible ...)

So i have many many many questions ... but i will ask you only one : what do you think about all these things... some ideas ?

http://www.doctrine-project.org/

I am not a fan of implementing an ORM purely for the sake of having an ORM in the core.

We of course have to consider numerous factors, including
A: Who would it benefit and who would it hurt?
- if adding an ORM benefits only the professional coders, but adds a serious learning curve onto anybody else that tries to write code for CMSMS (even a UDT) then that's a big problem.
- if adding an ORM doesn't have any real tangible benefit for site designers, and developers then what is the point.

B: What would it break?
- If adopting an ORM would require modifications to every module, or for us to jump through hoops to allow older modules to work while we phase in the ORM then there's a serious consideration.
- As you said, it's pointless, and problematic to have two database abstraction layers.

C: What effort would be required to adopt it and convert CMSMS?

In Ted's original 2.0 project he 'wrote' an ORM, then didn't like it, and revised it, and wrote another one. I used it a bit, but essentially it did little except for providing a convenient and consistent method for saving and loading objects. It didn't solve the complex queries that are needed in most of the modules these days, and if anything made them more difficult. We abandoned that ORM when we abandoned the original 2.0 project simply because I didn't see the benefit outweighing the cost.

Now that being said, there were a few features of ted's original ORM (particularly related to the query language stuff) that I wouldn't mind stealing and implementing into our (highly trimmed and customized) version of adodb_lite/

I don't mind breaking some things (modules, and installs) for the sake of the greater good (we're breaking some things in the new 2.0), but the benefits have to be tangible for the designer/developer and/or the end user.

So in essence... I have yet to be sold on an ORM for CMSMS. Though if I was starting a new project from scratch I would entertain using one.

i'm glad to read you Calguy because we had so much interesting discussions about this subject during the last Geekmoot

after reading, i'm mostly agree with your point of view and ... like the last year ... i'm thinking i will continue to use my own framework.

btw, why do i need an ORM : because i wrote a lot of modules and like i showed you last year : the lack of Adodb when you want used the system "named queries" or where you need to write the table's specifications ... all this stuff are too useless for my little brain...

for what benefice : less code, less bug and less time lost with useless code .. !
seriously ...what is that mess ?? why all this code only for 1 sql Request

edit : a reminder => my framework works like CgExtension does : it's not a core modification but more a simple module which is extended by others

bess wrote:my framework works like CgExtension does : it's not a core modification but more a simple module which is extended by others

Is your framework available at CMSMS forge?

Found nothing ...

not yet

simply because like i said : it was made for my own necessity.

I need to rewrite it for a new project this week. I may push it on Github if you would like to take a look inside

bess wrote:I may push it on Github if you would like to take a look inside

+1

okay ... i just found this documentation => http://phplens.com/lens/adodb/docs-active-record.htm

i must take a look on it because it could seem that all my work is useless ...

Hmm, too bad ... config param "use_adodb_lite" was removed in current cmsms version.

How can I use adodb full now (without a second db connection)?

I doubt ... cmsmadesimple use adodb or adodblite ?

btw, i try to create a small demonstration of my code before push it on Github. I'm not sur to be able to do it before january 2013. I'll send you a message as soon as it will be done

https://github.com/besstiolle

bess wrote:I doubt ... cmsmadesimple use adodb or adodblite ?

Maybe the dev chief can clearing this ...

CMSMS only uses it's own highly customized and highly trimmed version of adodb_lite. We don't support adodb (full) any more.

Thanx for the fast answer!

@bess

With this condition your framework will get a new sense ...

indeed.

I m not at home for few days. I 'll post a message here as soon as I 'll push my code on github

Sounds great - bonne année ...

happy new year everybody

So i'm quite busy these days but i took time yesterday to (re)write my personal framework for a public module.

everything is on Github : https://github.com/besstiolle/orm-ms

i encourage you to follow this repository because the code is only an alpha version of my goal and will change a lot these next days

You will find the source of the module "Orm", the core of my work. It's a simple cmsms's module.
You will also find the source of the module "Poc", it's a (very) simple example of the use of the Orm. it isn't completed at this moment

What is functionnal :
- you can describe your entities (see /Poc/lib/class.entity.***.php for some examples)
- you don't have to specify something else, everything is automatised (autoload powa !)
- you can also automatise the creation of your tables, create/drop (see /Poc/method.(un)install.php)

Should also work (but i didn't test it since yesterday, and i didn't made any example)
- insert, update, delete, select [all], ...
- select by an example
- deep search (eg: select all customers where customers.adresses.country is "France")
- a (too much) simple caching to avoid too much request on database
- a simple debug system (Trace.debug|info|warn|error("hello"))
- a Sorting declaration let you describe how to sort a list of your entites

You can use these declarations for your entities :
- primaryKey, foreignKey (0,1->N) , AssociateKey (N<->N)
- Date, TimeStamp, Integer, Number, String, Buffer ....
- Size
- Nullable, or not

Since my presentation during the geekmoot i removed (or i will remove) some stuff because my (new) opignon is that an Orm must only do Orm stuff and not more. So i removed :
- the validator system (regex validation on a field)
- the html generator system ( a database field => a html field)
- the search entity, it was useless because basically it's like doing a select by example.

Of course, it's only documented in french but i will translate it as soon as possible.

At this point, i very happy to doing this work : it's easy to understand, to implement and it doesn't need any massive modifications in you current code to work.

and obviously it's using only the Api of cmsmadesimple

returns and notices are obviously more than welcome!