orm ideas

[tpet...@gmail.com]

over the last 48 hours i've literally been breaking apart the wheels
code left and right (you did an outstanding job per!)

upon doing so there are some limitations with the current orm that i
would like to address:

1) noticed that the wheels orm is integrated into the framework. might
i suggest that wheels have some sort of plugin component like rails.
this would make it easier for other orms to be developed and for
people to switch back and forth?

2) there is no current support of guids or uuids with sqlserver. i
personally only use guids for my primary keys in my databases (been
burned too may times with identity columns).

3) no multi-column primary key support.

4) the adapters for the supported databases are very lite. there isn't
enough information being inspected from the database.

now this post was not meant as a rant as i would like the team's
permission to address these issues. i have some experience writing
orms and would like to put my time where my mouth is.

[Chris Peters]

What we need to do is start a discussion around Release 0.8 and what
should be scoped for that release. I think ORM issues would be a great
candidate for discussion. What Per wrote was great, but it was also
only the start. We have a ton of room to grow.

I also want to for everyone to work on what interests them the most.
If you're the ORM guy, Tony, then we'd be glad to have you work on
that area. Personally, I have little experience with this area, so I
know I'll be of little use for that.

That said, if we do go with a plugin-type system for ORMs, I think we
should keep the "default" ORM as close to Rails as possible. But it
would definitely be cool to see the ability to plug in the other ORM
systems like Transfer and Reactor.

Everyone... If you have any major ideas that you'd like to put up for
discussion, please create a topic for it. And please help us discuss
the issues. I'm increasingly impressed with the talent that I'm seeing
from everyone, so it would be a major waste for you to not at least
contribute to discussion!

[Mike Haggerty]

I've been reading the frenzy of emails on this list since Chris took over, and I am really excited to see where Wheels is heading.  I haven't had the time to help contribute much, as I don't have any new projects where I can start using this framework yet, but I would love to try it in the future.

So, with that said, everything I am about to say should be understood in light of the fact that I am an outside observer and not a contributor.  However, I, like everyone, have $0.02.

From my short journeys into the Rails world, it would seem as if their MO is 'our way or the highway.'  They set out with the mission of developing a very rigid framework that didn't bend to the whims of anyone.  Of course they have plugins, but those extend the framework, as opposed to replacing large chunks of it.  From my understanding, you HAVE to use activerecord if you want to use Rails.  Of course you can write plugins that would extend the activerecord ORM to handle whatever unique situation you're dealing with, but the core ORM system would still remain the same.  I think I recall them even taking AWAY some ORM functionality for the 2.0 release and moving it into a plugin b/c the core system was beginning to feel a little bloated.

The number of different frameworks I've come across in the CF world all seem to take a different approach.  They want offer you the entire world.  Come one, come all.  Bring your ORMs and your IOCs and your service layers.  You can configure any framework in any number of different (and confusing -- to the noob) ways!  Of course there are many advantages to this, but the learning curve can be steep.

So all that to say that I would be opposed to allowing multiple different ORMs access into the Wheels framework.  Let's build on what Per has created until there's a good solid core, and any extensibility can be thrown into a plugin to work ALONG SIDE not INSTEAD OF the Wheels ORM.  I just think a lot of time could be spent trying to make Wheels a one size fits all solution like the other CF frameworks, and it would deviate from it's original intent.

But, then again, I'm not actually using or developing this system, and talk is cheap, so I'll shut up now :)

Mike

-- 
Michael Haggerty
Internet Applications Developer
SiteVision, Inc.
<e>mi...@sitevision.com</e>
<p>540.343.8322 x116</p>

[Per Djurner]

Thanks, here are some of my thoughts on this:

GUID/UUID support would be a great addition to the framework!
Same with multi-column support (but this one might be a little more
complex to implement).

As for plugin support / allowing other ORMs... not so sure about that one.
One of Wheels strengths (when we actually have a 1.0 release with
proper documentation) will be that everything IS integrated in my
opinion.
No need to go to three different websites to read docs etc.

About more database introspection:
Sure, that would be great as long as we can keep supporting a wide
range of databases.
The more introspection we add, the harder it will get to support all databases.
I think we should use ColdFusion's built-in introspection whenever
possible (cfdbinfo) to avoid complicating the code base.

/ Per

[Per Djurner]

I agreed 100%!

[Mike Haggerty]

This isn't to say that your suggestions for additions to the core Wheels ORM aren't valid, tpetruzzi.  I just think we would keep it all in the family, if you know what I mean.

Great idea about brainstorming new features for 0.8, Chris.

Mike

[Peter Amiri]

Mike,

I agree whit your analysis. I would offer a couple of cents to the discussion as well. I am intrigued as to the speed at which RoR permeated the development community. I believe this was partially due to the speed at which information spreads on the internet now days and partially due to perception, whether right or not, that RoR enables speedy development of Web 2.0 sites. But I think another aspect that fueled the adoption was the perception that RoR development was easier. Frankly I would argue with this one, having used CFML for over 11 years I found the Ruby syntax a step backwards in simplicity and readability. 

Having said all this, I think there is a tremendous opportunity here to make a framework that is probably more constraining than the other CF frameworks but the ease of use from a developer perspective is much greater. Couple this with another project that I am involved with which is the OpenBlueDragon initiative and we should be able to match more of the RoR functionality out of the box.

I have to say I am very excited about seeing others take a greater interest in this framework and actually working towards feature completion.

-Peter

[tpet...@gmail.com]

thanks for the feed back everyone. all i want to do is contribute to
this project however i can. for once i see that cf finally has a
framework to get excited about.

taking into account the suggestion presented, i will build upon the
existing orm and add the guid/uuid and multi column pk support (wife
is going out of town next week so i need something to do).

per - you read my mind with using cfdbinfo. as a matter of fact i was
exploring how to integrate it into the existing orm right before i
read this thread.

peter - it's awesome that you are on the OpenBlueDragon initiative.
not knowing too much about BD, would using cfdbinfo cause wheels to be
incompatible with BD?

> > <e>m...@sitevision.com</e>
> > <p>540.343.8322 x116</p>

[Peter Amiri]

Tony,

Although cfdbinfo is not currently supported by BD it doesn't mean it
would be in the open source version. The first code drop of the open
source version is actually taking place tomorrow morning. I know it
will have a plugin architecture where the core language can be
extended. Therefore, this might be a very easy upgrade if in fact a
java library can be found to just wrap around. So the short answer
would be look at cfdbinfo and see how you would implement what you
need with that and I will get more information about OpenBD support.

-Peter

[Per Djurner]

Hi Tony, just curious about your usage of UUID/GUID, do you normally
create them in ColdFusion or do you let SQL Server handle the
creation?
/ Per

On Fri, May 2, 2008 at 9:41 AM, tpet...@gmail.com <tpet...@gmail.com> wrote:
>

[tpet...@gmail.com]

I create them in CF like so:

insert("-", CreateUUID(), 23)

yeah, i know it's not the best, but hey, it's easy and quick. the
whole reason for doing this in CF is because so i don't have to try to
pull some wizardary to get the inserted value of the guid, like you do
with identities.

On May 9, 11:21 am, "Per Djurner" <per.djur...@gmail.com> wrote:
> Hi Tony, just curious about your usage of UUID/GUID, do you normally
> create them in ColdFusion or do you let SQL Server handle the
> creation?
> / Per
>

[tpet...@gmail.com]

per, when you read this, please contact me by email at
tpet...@gmail.com. there are some question that i need to ask you
off the list about the orm.