RE: [JBoss-dev] Finders, Selectors and ... deleters?
Thanks men. Sorry to be a nag.. :) Hope you don't mind. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Friday, January 17, 2003 1:42 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters? > > > It is already in the JBoss 4.0 task list. > > http://sourceforge.net/pm/ > task.php?func=detailtask&project_task_id=68960&group_id=22866&group_proj > ect_id=15043 > > -dain > > On Friday, January 17, 2003, at 12:23 PM, Bill Burke wrote: > > > Please archive this on the Persistence forum. Thanks guys. > > > > Bill > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED]]On Behalf Of > >> Dain > >> Sundstrom > >> Sent: Friday, January 17, 2003 1:14 PM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters? > >> > >> > >> On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote: > >> > >>> This leaves the JBoss-QL part read-only (it just qualifies the > >>> instances to > >>> be deleted). We know we're deleting Transactions as the method would > >>> be on > >>> the home interface for the Transaction EJB. > >> > >> I think we should support a full CRUD language. Specifically, I mean > >> that the user should not be restricted to just specifying the WHERE > >> clause, but they should be required to specify a DELETE clause also. > >> Then we just put in a restriction that a remove method on the home > >> interface is only allowed to remove entities of the current type. > >> This > >> is the same restriction finders have. > >> > >> The reason I think we should have a full CRUD language is it allows an > >> ejbSelect style method (although we may call it something else) to > >> delete any set of objects with a single operation. This will be > >> particularly useful to delete a subset of related objects. > >> > >> -dain > >> > >> > >> > >> --- > >> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts > >> will > >> allow you to extend the highest allowed 128 bit encryption to all your > >> clients even if they use browsers that are limited to 40 bit > >> encryption. > >> Get a guide > >> here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > >> ___ > >> Jboss-development mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > --- > > This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts > > will > > allow you to extend the highest allowed 128 bit encryption to all your > > clients even if they use browsers that are limited to 40 bit > > encryption. > > Get a guide > > here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will > allow you to extend the highest allowed 128 bit encryption to all your > clients even if they use browsers that are limited to 40 bit encryption. > Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Finders, Selectors and ... deleters?
It is already in the JBoss 4.0 task list. http://sourceforge.net/pm/ task.php?func=detailtask&project_task_id=68960&group_id=22866&group_proj ect_id=15043 -dain On Friday, January 17, 2003, at 12:23 PM, Bill Burke wrote: Please archive this on the Persistence forum. Thanks guys. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Friday, January 17, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters? On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote: This leaves the JBoss-QL part read-only (it just qualifies the instances to be deleted). We know we're deleting Transactions as the method would be on the home interface for the Transaction EJB. I think we should support a full CRUD language. Specifically, I mean that the user should not be restricted to just specifying the WHERE clause, but they should be required to specify a DELETE clause also. Then we just put in a restriction that a remove method on the home interface is only allowed to remove entities of the current type. This is the same restriction finders have. The reason I think we should have a full CRUD language is it allows an ejbSelect style method (although we may call it something else) to delete any set of objects with a single operation. This will be particularly useful to delete a subset of related objects. -dain --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Finders, Selectors and ... deleters?
I opened a topic with the title "Should we just use SQL-99 for JBoss-QL?" > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Friday, January 17, 2003 10:24 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Finders, Selectors and ... deleters? > > > Please archive this on the Persistence forum. Thanks guys. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > > Sundstrom > > Sent: Friday, January 17, 2003 1:14 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters? > > > > > > On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote: > > > > > This leaves the JBoss-QL part read-only (it just qualifies the > > > instances to > > > be deleted). We know we're deleting Transactions as the method would > > > be on > > > the home interface for the Transaction EJB. > > > > I think we should support a full CRUD language. Specifically, I mean > > that the user should not be restricted to just specifying the WHERE > > clause, but they should be required to specify a DELETE clause also. > > Then we just put in a restriction that a remove method on the home > > interface is only allowed to remove entities of the current type. This > > is the same restriction finders have. > > > > The reason I think we should have a full CRUD language is it allows an > > ejbSelect style method (although we may call it something else) to > > delete any set of objects with a single operation. This will be > > particularly useful to delete a subset of related objects. > > > > -dain > > > > > > > > --- > > This SF.NET email is sponsored by: Thawte.com - A 128-bit > supercerts will > > allow you to extend the highest allowed 128 bit encryption to all your > > clients even if they use browsers that are limited to 40 bit encryption. > > Get a guide > here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will > allow you to extend the highest allowed 128 bit encryption to all your > clients even if they use browsers that are limited to 40 bit encryption. > Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Finders, Selectors and ... deleters?
Please archive this on the Persistence forum. Thanks guys. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Friday, January 17, 2003 1:14 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters? > > > On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote: > > > This leaves the JBoss-QL part read-only (it just qualifies the > > instances to > > be deleted). We know we're deleting Transactions as the method would > > be on > > the home interface for the Transaction EJB. > > I think we should support a full CRUD language. Specifically, I mean > that the user should not be restricted to just specifying the WHERE > clause, but they should be required to specify a DELETE clause also. > Then we just put in a restriction that a remove method on the home > interface is only allowed to remove entities of the current type. This > is the same restriction finders have. > > The reason I think we should have a full CRUD language is it allows an > ejbSelect style method (although we may call it something else) to > delete any set of objects with a single operation. This will be > particularly useful to delete a subset of related objects. > > -dain > > > > --- > This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will > allow you to extend the highest allowed 128 bit encryption to all your > clients even if they use browsers that are limited to 40 bit encryption. > Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Finders, Selectors and ... deleters?
On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote: This leaves the JBoss-QL part read-only (it just qualifies the instances to be deleted). We know we're deleting Transactions as the method would be on the home interface for the Transaction EJB. I think we should support a full CRUD language. Specifically, I mean that the user should not be restricted to just specifying the WHERE clause, but they should be required to specify a DELETE clause also. Then we just put in a restriction that a remove method on the home interface is only allowed to remove entities of the current type. This is the same restriction finders have. The reason I think we should have a full CRUD language is it allows an ejbSelect style method (although we may call it something else) to delete any set of objects with a single operation. This will be particularly useful to delete a subset of related objects. -dain --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Finders, Selectors and ... deleters?
> I was thinking about something while looking at my application's > database behaviour... in many cases it is very inefficient to use a > finder method together with remove() for large collections. It would be > so much more efficient to have something like > >public int deleteByCode(int code); > > > deleteByCode > > int > > > delete from Transactions t where t.code = ?1 > > > > This all of course integrated with the cache so that it invalidates > objects that are already loaded, etc. > This is the same semantic (i.e. remove a load of stuff :-) that we need to improve to make efficient. I would be fairly easy to extend that to user-defined operations. I'm against adding delete (or insert and update) semantics to JBoss-QL though - that changes the nature of the language from read-only to read-write. Instead you could define a DeleteMethod as: deleteByCode int where code = ?1 or, using values from the another entity via a subquery deleteByCode int where code in (select x.code from another x where x.flag = ?1) This leaves the JBoss-QL part read-only (it just qualifies the instances to be deleted). We know we're deleting Transactions as the method would be on the home interface for the Transaction EJB. It would be easy enough to extend this to bulk update as well - ok, easy if you limited the update to single-valued fields. Bulk create would be harder (need to pass in a lot of data), and probably unnecessary given we plan to have batch insert anyway. --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
