Thanks for the comments... (Dam it is hot here in Minneapolis, 97 degrees
F, I got to get my airconditioner down from the attic and installed ASAP)
> Maybe as a first question - how 'done' do you consider the basic
> architecture of the CMP2.0 module? Done enough that there aren't going
> to be any major structural changes, or might it get turned upside down?
>
> As a frame of reference for my frame of mind, in my statements/questions
> below, I'm assuming that it _won't_ get turned upside down.
>
I consider CMP fields done, and don't expect them to change much. I am just
starting on designing relationships and this might cause some changes. As
for queries, they are completely up in the air. The EJB-QL implementation
may cause some global changes, but I don't think that will happen.
> >
> > The query-method element is right out of the EJB 2.0 spec. The
> > <declared-sql> element is similar to jaws finder element, except I have
> > broken the query element into from and where.
>
>
> Thank you. having them combined made some things really painful. This is
> something I was going to change in JAWS.
I saw you comment in the code and broke it in two...
> > I also support order as jaws
> > did. The new code doesn't have the new pre-load logic, but I will add
> > something similar in phase 3, where I'll add ejb-ql support.
>
>
> Do you have any objection to Bill or I getting the initial underpinnings
> in there now? It's changed quite a bit since the version of JAWS that
> you (apparently) based your new work on.
I only implemented queries so people can play with my code. I'm not sure if
it would be worth your time to mess with my query code as most of it may go.
I also plan on implementing the <eager-load> stuff on a per query basis.
That way you can get just the data you need back.
> On a related (triggering, in fact) note: do you see your CMP
> implementation obsoleting JAWS, or augmenting it? Personally, I had
> intended on taking a chainsaw through JAWS anyway, so I wouldn't mind
> seeing it obsoleted. If it's obsoleted, I really think we may as well
> get more people than you working on it - hence the above question.
>
> Or if not, I'll find something else to do.
I do intend on obsoleting JAWS; the new stuff is a rewritten fork of JAWS
(the architecture rocked). The new code is backwards compatable with EJB
1.x CMP (it is required by the spec). Most of what is left is mostly a one
person job. Most of it is design, the code should be fairly simple. I have
lots of time to work on this (I'm on vacation for several months, benefit of
being an independent consultant). If you really want to help and see a
section to break off, email me. (but EJB-QL is mine... i've been jonesing
to write it).
> >
> > If you find any bugs or would like to request a feature, please email
me. I
> > will fix bugs as they are discovered, and feature req1uests I will
> > definitely think over.
>
>
> I really think that these should be posted on the sourceforge site -
> bugs because it lets us get more bandwidth - people other than you can
> fix the bugs, which means that more eyes will be on the code, which will
> lead to better code. That's why it's open source, after all.
I agree, it could get lost in my mail box. I could die and it would be lost
forever. But I may not notice it if it is only posted to source forge.
-dain
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
