[Ogden] Ogden and sequel
Mark Van De Vyver
I'd like to canvas thoughts on setting a project goal of incorporating
some of Sequel into/under Ogden?
Exactly what parts of Sequel is open to debate and implementation.
My initial thought is to include as much as possible that does not
intrude on the managing/enchanting of Og classes.
>From my look at Sequel it is more advanced than Og on several
functional fronts and has some good user and dev momentum.
So ConnectionPool, Database/Adapter, Dataset, Model and query
generation, etc would be Sequel's - overridden by Ogden specific
methods where required to knit with Og enchanting.
I built a static snapshot of Sequel into the DBI adapter, because I
wasn't aware of what might be possible, and it does look feasible to
me - and I'm just a programming amateur and Ruby novice :)
Ideally Sequel would be a required package instead of having a static
snapshot of Sequel built into Ogden.
>From my dry run this can be done if:
- some changes are made to Ogden
- some changes are made to Sequel
Hopefully we wouldn't affect Sequel's behavior adversely, but we might
need some changes to the way code is organized. Example Sequel::Model
methods would need to be moved to some module so that Ogden can
include them when enchanting a class.
If Sequel dev's are open to exploring this, Ogden devs would need to
contribute any changes to Sequel to get this done.
Given so much of Ogden's non-enchanting related code would be sequels
it seems a little redundant to try and knock the whole of Ogden into
shape before starting this effort... we'd just polish many (most?)
parts of Ogden only to drop them.
If this was a path taken it would seem that Ogdens two major goals would be:
- Clean up the meta-coding (code, documentation and specs)
- Incorporate Sequel (adapt code and adapt specs)
Thoughts?
Mark
_______________________________________________
Ogden-developers mailing list
Ogden-de...@rubyforge.org
http://rubyforge.org/mailman/listinfo/ogden-developers
Judson Lester
Hi,
I'd like to canvas thoughts on setting a project goal of incorporating
some of Sequel into/under Ogden?
Exactly what parts of Sequel is open to debate and implementation.
My initial thought is to include as much as possible that does not
intrude on the managing/enchanting of Og classes.
>From my look at Sequel it is more advanced than Og on several
functional fronts and has some good user and dev momentum.
So ConnectionPool, Database/Adapter, Dataset, Model and query
generation, etc would be Sequel's - overridden by Ogden specific
To be honest, I'm at a loss as to the motivation. I can see the virtues of examining something like the Sequel method chaining technique ( post.where(:name => "judson")) but the reason that Sequel would overwhelm the code in Ogden is that they have very different focuses. Strictly speaking, I can't see how Sequel is an ORM at all. It's a wrapper on SQL, which is certainly nice, but rows of databases are mapped to Ruby hashes. That's a far cry from an actual ORM.
Quite possibly, Sequel has some good ideas in terms of raw SQL access, and it'd be worth looking at how to defer queries until they're needed, for instance. It's possible that it would be worth comparing the pooling mechanism from Facets that Ogden uses to the Sequel connection pool.
But I tend very much to think that, short of discarding Og and starting a new project, the first step has got to be cleaning that codebase up. Otherwise there's no real sane way to make any changes.
Judson
--
Your subnet is currently 169.254.0.0/16. You are likely to be eaten by a grue.
Mark Van De Vyver
>
>
>
> On Dec 19, 2007 4:36 PM, Mark Van De Vyver <mvy...@gmail.com> wrote:
> > Hi,
> > I'd like to canvas thoughts on setting a project goal of incorporating
> > some of Sequel into/under Ogden?
> >
> > Exactly what parts of Sequel is open to debate and implementation.
> > My initial thought is to include as much as possible that does not
> > intrude on the managing/enchanting of Og classes.
> > >From my look at Sequel it is more advanced than Og on several
> > functional fronts and has some good user and dev momentum.
> > So ConnectionPool, Database/Adapter, Dataset, Model and query
> > generation, etc would be Sequel's - overridden by Ogden specific
> >
>
> To be honest, I'm at a loss as to the motivation. I can see the virtues of
AFAICT Sequel would not inhibit anything Ogden currently can do.
The motive then is to get enhanced functionality, docs, spec and
(possibly) user community with minimal additional effort.
> examining something like the Sequel method chaining technique (
> post.where(:name => "judson")) but the reason that Sequel would overwhelm
> the code in Ogden is that they have very different focuses.
Filtering, datasets, sub-queries are some benefits. I think the
ConnectionPooling is better in Sequel and there may be other
'lower-level' parts that added to Ogden?
> Strictly
> speaking, I can't see how Sequel is an ORM at all. It's a wrapper on SQL,
> which is certainly nice, but rows of databases are mapped to Ruby hashes.
No that (rows as hashes) is not the complete story.
As I say we don't seem to lose anything, yes you can get the data as a
hash _AND_ as object attributes.
<quote>
A model instances stores its values as a hash:
post.values #=> {:id => 123, :category => 'ruby', :title => 'hello world'}
You can read the record values as object attributes:
post.id #=> 123
post.title #=> 'hello world'
You can also change record values:
post.title = 'hey there'
post.save
</quote>
> That's a far cry from an actual ORM.
I won't proclaim to be an O/RM guru, but it seems to me that Sequel
provides much of the tools required by an ORM? Or at least useful
when implementing an ORM?
Furthermore, Ogden can always override a Sequel method where doesn't
fit perfectly/well.
My experience was this is in very few places.
> Quite possibly, Sequel has some good ideas in terms of raw SQL access, and
> it'd be worth looking at how to defer queries until they're needed, for
> instance. It's possible that it would be worth comparing the pooling
> mechanism from Facets that Ogden uses to the Sequel connection pool.
>
> But I tend very much to think that, short of discarding Og and starting a
> new project, the first step has got to be cleaning that codebase up.
> Otherwise there's no real sane way to make any changes.
My experience was that it was quicker to incorporate Sequel's
functionality than to: decipher, debug, spec and document what Og was
doing. In addition we get the results of a much wider dev effort and
wider user experiences.
Bear in mind I'm referring mainly to the non-enchanting related code.
Sequel takes a different tack to creating a table, but again it seems
to me their code is well suited to Ogdens task.
Speculation:
When looking at the enchanting code it may well be easier to implement
some things by calling Sequel's methods.
This I've not fully looked into and is pure conjecture.
> Judson
> --
> Your subnet is currently 169.254.0.0/16. You are likely to be eaten by a
> grue.
Trans
On Dec 19, 9:07 pm, "Mark Van De Vyver" <mvy...@gmail.com> wrote:
> On Dec 20, 2007 12:36 PM, Judson Lester <nya...@gmail.com> wrote:
> > To be honest, I'm at a loss as to the motivation. I can see the virtues of
I have to agree with Judson.
> AFAICT Sequel would not inhibit anything Ogden currently can do.
> The motive then is to get enhanced functionality, docs, spec and
> (possibly) user community with minimal additional effort.
Not of those things really matter except functionality, and that's
were I'm not seeing how this fits together. No doubt there are
elements of Sequel that can be of benefit to Og, but retro-fitting the
whole of Og to work on Sequel's terms doesn't make much sense to me.
Maybe I'm wrong. Maybe I just don't see the bigger picture that you
do. But even so, it would be a huge undertaking --so much so Judson
makes a good point, that we may as well start over. That's not the
goal however. The goal is to improve Og, and we need do that
incrementally, little by little.
> > examining something like the Sequel method chaining technique (
> > post.where(:name => "judson")) but the reason that Sequel would overwhelm
> > the code in Ogden is that they have very different focuses.
>
> Filtering, datasets, sub-queries are some benefits. I think the
> ConnectionPooling is better in Sequel and there may be other
> 'lower-level' parts that added to Ogden?
We can certainly look into the pooling area of Sequel and see if it is
useful to us.
> I won't proclaim to be an O/RM guru, but it seems to me that Sequel
> provides much of the tools required by an ORM? Or at least useful
> when implementing an ORM?
> Furthermore, Ogden can always override a Sequel method where doesn't
> fit perfectly/well.
> My experience was this is in very few places.
If Sequel provides everything needed except for a "very few places"
why not just enhance Sequel instead?
> > Quite possibly, Sequel has some good ideas in terms of raw SQL access, and
> > it'd be worth looking at how to defer queries until they're needed, for
> > instance. It's possible that it would be worth comparing the pooling
> > mechanism from Facets that Ogden uses to the Sequel connection pool.
>
> > But I tend very much to think that, short of discarding Og and starting a
> > new project, the first step has got to be cleaning that codebase up.
> > Otherwise there's no real sane way to make any changes.
>
> My experience was that it was quicker to incorporate Sequel's
> functionality than to: decipher, debug, spec and document what Og was
> doing. In addition we get the results of a much wider dev effort and
> wider user experiences.
> Bear in mind I'm referring mainly to the non-enchanting related code.
>
> Sequel takes a different tack to creating a table, but again it seems
> to me their code is well suited to Ogdens task.
>
> Speculation:
> When looking at the enchanting code it may well be easier to implement
> some things by calling Sequel's methods.
> This I've not fully looked into and is pure conjecture.
Og is all about the enchanting. Without it, there is no Og. Is your
suggestion that we should rewrite Og's enchanting on top of Sequel?
T.
Mark Van De Vyver
>
>
> On Dec 19, 9:07 pm, "Mark Van De Vyver" <mvy...@gmail.com> wrote:
> > On Dec 20, 2007 12:36 PM, Judson Lester <nya...@gmail.com> wrote:
> > > To be honest, I'm at a loss as to the motivation. I can see the virtues of
>
> I have to agree with Judson.
OK
> > AFAICT Sequel would not inhibit anything Ogden currently can do.
> > The motive then is to get enhanced functionality, docs, spec and
> > (possibly) user community with minimal additional effort.
>
> Not of those things really matter except functionality, and that's
Correct.
> were I'm not seeing how this fits together. No doubt there are
> elements of Sequel that can be of benefit to Og, but retro-fitting the
> whole of Og to work on Sequel's terms doesn't make much sense to me.
Fair enough.
> Maybe I'm wrong. Maybe I just don't see the bigger picture that you
> do. But even so, it would be a huge undertaking --so much so Judson
> makes a good point, that we may as well start over. That's not the
> goal however. The goal is to improve Og, and we need do that
> incrementally, little by little.
OK. I just saw little point in reinventing the wheel when
implementing functionality that Sequel provides.
> > > examining something like the Sequel method chaining technique (
> > > post.where(:name => "judson")) but the reason that Sequel would overwhelm
> > > the code in Ogden is that they have very different focuses.
> >
> > Filtering, datasets, sub-queries are some benefits. I think the
> > ConnectionPooling is better in Sequel and there may be other
> > 'lower-level' parts that added to Ogden?
>
> We can certainly look into the pooling area of Sequel and see if it is
> useful to us.
>
> > I won't proclaim to be an O/RM guru, but it seems to me that Sequel
> > provides much of the tools required by an ORM? Or at least useful
> > when implementing an ORM?
> > Furthermore, Ogden can always override a Sequel method where doesn't
> > fit perfectly/well.
> > My experience was this is in very few places.
>
> If Sequel provides everything needed except for a "very few places"
That isn't what I said - close to the opposite though.
> why not just enhance Sequel instead?
That would require many major changes.
> > > Quite possibly, Sequel has some good ideas in terms of raw SQL access, and
> > > it'd be worth looking at how to defer queries until they're needed, for
> > > instance. It's possible that it would be worth comparing the pooling
> > > mechanism from Facets that Ogden uses to the Sequel connection pool.
> >
> > > But I tend very much to think that, short of discarding Og and starting a
> > > new project, the first step has got to be cleaning that codebase up.
> > > Otherwise there's no real sane way to make any changes.
> >
> > My experience was that it was quicker to incorporate Sequel's
> > functionality than to: decipher, debug, spec and document what Og was
> > doing. In addition we get the results of a much wider dev effort and
> > wider user experiences.
> > Bear in mind I'm referring mainly to the non-enchanting related code.
> >
> > Sequel takes a different tack to creating a table, but again it seems
> > to me their code is well suited to Ogdens task.
> >
> > Speculation:
> > When looking at the enchanting code it may well be easier to implement
> > some things by calling Sequel's methods.
> > This I've not fully looked into and is pure conjecture.
>
> Og is all about the enchanting. Without it, there is no Og. Is your
> suggestion that we should rewrite Og's enchanting on top of Sequel?
I never mentioned a complete enchanting rewrite - I just listed your
original todo nomination.
Some enchanting methods would require tweaking, but that is far from
suggesting a rewrite or abandoning what is there in terms of
enchanting code.
Seems I'm Robinson Crusoe on this idea :)
Cheers
Trans
On Dec 20, 5:32 pm, "Mark Van De Vyver" <mvy...@gmail.com> wrote:
> Seems I'm Robinson Crusoe on this idea :)
I'm just not seeing it really. When you mentioned that your idea would
ultimately have Og depend on Sequel I really felt it wasn't the right
direction. I'm all for exchanging code, so don't think I'm against
garnering what we can from Sequel. But I also see Og as being a self
sufficient ORM system.
You are more then welcome to make a svn branch and try out whatever
you like of course.
Mark Van De Vyver
>
>
> On Dec 20, 5:32 pm, "Mark Van De Vyver" <mvy...@gmail.com> wrote:
>
> > Seems I'm Robinson Crusoe on this idea :)
>
> I'm just not seeing it really. When you mentioned that your idea would
> ultimately have Og depend on Sequel I really felt it wasn't the right
> direction. I'm all for exchanging code, so don't think I'm against
> garnering what we can from Sequel. But I also see Og as being a self
> sufficient ORM system.
Yes, a difference of opinion one when a dependency means Ogden is not
self-sufficient :)
Does this mean there is an in principle opposition to such dependencies?
Specifically:
- Validatable gem
- Paginator gem
> You are more then welcome to make a svn branch and try out whatever
> you like of course.
I'm against fracturing efforts. If its not a convincing idea its not
a convincing idea!
I'll branch if I need something can't live without and it's rejected
from the main line of Ogden.
Cheers
Mark Van De Vyver
On Dec 21, 2007 10:40 AM, Trans <tran...@gmail.com> wrote:
>
>
> On Dec 20, 5:32 pm, "Mark Van De Vyver" <mvy...@gmail.com> wrote:
>
> > Seems I'm Robinson Crusoe on this idea :)
>
> I'm just not seeing it really. When you mentioned that your idea would
> ultimately have Og depend on Sequel I really felt it wasn't the right
> direction. I'm all for exchanging code, so don't think I'm against
I contributed a patch to Og that physically moved some Sequel 0.3.x
code into Og.
Just for the record in case anyone comes searching alone this path....
I'm not tracking and patching all the bug fixes and enhancements that
occur in Sequel - that would raise redundant effort to the extreme :)
If I ever do jump into this... the maximum effectiveness path is to
contribute any changes to a Ogden branch and/or Sequel (if they are
receptive).
Judson Lester
I contributed a patch to Og that physically moved some Sequel 0.3.x
code into Og.
Just for the record in case anyone comes searching alone this path....
I'm not tracking and patching all the bug fixes and enhancements that
occur in Sequel - that would raise redundant effort to the extreme :)
If I ever do jump into this... the maximum effectiveness path is to
contribute any changes to a Ogden branch and/or Sequel (if they are
receptive).
Anything you want to do along those lines would be excellent. The license for Sequel is very permissive - just be sure to credit copyright for "significant portions" to Sharon.
And don't be afraid to start a branch. It's the easiest way to do extensive work and make it available.
Judson
--
Your subnet is currently 169.254.0.0/16 . You are likely to be eaten by a grue.