Forum
|
|
Fornax-Platform
Forum |
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
[sculptor] pagination
by Steffen Stundzig
::
Rate this Message:
Hi all,
there are any thoughts about pagination of hibernate queries in sculptor? We could use the criteria or the query api for that, but we need also propagation of the page parameters such firstResult and MaxResults in the Services and Repositories, so clients could use it. see hibernate reference regards |
|
|
Re: [sculptor] pagination
by Patrik Nordwall
::
Rate this Message:
Do you mean that you would like to have support for pagination in the built in queries, such as findAll?
If you write your own query (access object) I don't think there is anything stopping you from implementing pagination. You can pass your own (non persistent) objects holding these parameters. Please explain more. /Patrik
|
|
|
Re: [sculptor] pagination
by Steffen Stundzig
::
Rate this Message:
Hi,
what i mean is, e.g. on each findAll we could generate two findAll methods in services and/or repositories. The first is the current one, the second (new) contains 2 additional parameters (int firstResult, int maxResults). So we are compatible with older versions. These parameters could we very simple propagated to the criteria based FinderAccessApi-classes with criteria.setMaxResults() and so on. These feature is generic and should be paramterizable per generate.pagination. I'm implementing it in my local sculptor-generator project and be very appreciated if it could be in the main trunk. So the diff between the generator branches is a little bit smaller. ;-) I don't know how we could implement this without hibernate but with real JPA, but I'm sure it's possible. What do you mean? regards Steffen... Patrik Nordwall schrieb: > Do you mean that you would like to have support for pagination in the built > in queries, such as findAll? > If you write your own query (access object) I don't think there is anything > stopping you from implementing pagination. You can pass your own (non > persistent) objects holding these parameters. Please explain more. > /Patrik > > > Steffen Stundzig wrote: >> Hi all, >> >> there are any thoughts about pagination of hibernate queries in sculptor? >> >> We could use the criteria or the query api for that, but we need also >> propagation of the page parameters such firstResult and MaxResults in the >> Services and Repositories, so clients could use it. >> >> see >> http://www.hibernate.org/hib_docs/entitymanager/reference/en/html/objectstate.html#d0e763 >> hibernate reference >> >> regards >> > -- Steffen Stundzig Telefon: +49 (0) 341 / 231-0183-401 Telefax: +49 (0) 341 / 231-0183-411 Mobil: +49 (0) 151 / 173-9673-1 (!neu) http://itemis.de steffen.stundzig@... https://www.xing.com/profile/Steffen_Stundzig itemis AG Ludwig-Erhard-Straße 51 04103 Leipzig Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael Neuhaus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by Steffen Stundzig
::
Rate this Message:
Hi,
what i mean is, e.g. on each findAll we could generate two findAll methods in services and/or repositories. The first is the current one, the second (new) contains 2 additional parameters (int firstResult, int maxResults). So we are compatible with older versions. These parameters could we very simple propagated to the criteria based FinderAccessApi-classes with criteria.setMaxResults() and so on. These feature is generic and should be paramterizable per generate.pagination. I'm implementing it in my local sculptor-generator project and be very appreciated if it could be in the main trunk. So the diff between the generator branches is a little bit smaller. ;-) I don't know how we could implement this without hibernate but with real JPA, but I'm sure it's possible. What do you mean? regards Steffen... |
|
|
Re: [sculptor] pagination
by PaloT
::
Rate this Message:
Hello,
for one of our projects we implemented class called Paging. This class has interface which is easy to use at client side (pageSize, currentPage) and method which should calculate maxResults from this parameters. Paging has also boolean parameter "count" which will force service to return number of rows matching criteria and calculate maxPages for better GUI handling. Return parameter from service method return Paging and result set was embeded inside Paging. GUI paging component is nativelly working with Paging. When "count" is set to false another parameter in Paging will say how many pages forward we have to look that GUI can show only so many pages forward in pager. GUI handling in pager isn't as simple as it looks and every service call is expensive. Pavel On Sun, Nov 23, 2008 at 11:03 AM, Steffen Stundzig <stundzig@...> wrote: > > Hi, > > what i mean is, e.g. on each findAll we could generate two findAll methods > in services and/or repositories. The first is the current one, the second > (new) contains 2 additional parameters (int firstResult, int maxResults). So > we are compatible with older versions. > > These parameters could we very simple propagated to the criteria based > FinderAccessApi-classes with criteria.setMaxResults() and so on. > > These feature is generic and should be paramterizable per > generate.pagination. > > I'm implementing it in my local sculptor-generator project and be very > appreciated if it could be in the main trunk. So the diff between the > generator branches is a little bit smaller. ;-) > > I don't know how we could implement this without hibernate but with real > JPA, but I'm sure it's possible. > > > What do you mean? > > regards > Steffen... > > > -- > View this message in context: http://www.nabble.com/-sculptor--pagination-tp20636538s17564p20644645.html > Sent from the Fornax-Platform mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Fornax-developer mailing list > Fornax-developer@... > https://lists.sourceforge.net/lists/listinfo/fornax-developer > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by Steffen Stundzig
::
Rate this Message:
thanks pavel for this information. It sounds better than my first attempt.
The api of the example PlanetServiceImpl could looks like: ----- public List<Planet> findAll(ServiceContext ctx) { return planetRepository.findAll(); } public PagedResult<List<Planet>> findAll(ServiceContext ctx, Paging paging) { return planetRepository.findAll(paging); } ----- PagedResult is parameterized with the real finder result: ----- public class PagedResult<T> { public <T> getValues(); int currentPage; int pageSize; int maxResults; int maxNumberOfPages; // ctor // getter/setter } ----- Paging contains: ----- public class Paging { int currentPage = 0; int pageSize = 25; boolean calculateCount = true; // ctor // getter/setter } ------ It's correct? Could you explain these a little bit please? regards Steffen... |
|
|
Re: [sculptor] pagination
by Patrik Nordwall
::
Rate this Message:
Good ideas and would like to support paging in the standard queries, such as findAll. Let me know when you have something that you would like to contribute to trunk and I will review it and commit.
I assume that we need to support paging in FindByCriteriaAccessImpl. We need to add Paging and PagedResult classes in the framework, i.e. in package org.fornax.cartridges.sculptor.framework.domain To simplify usage in DSL we could define special types for PagedResult and Paging. Isn't the result always a List? public class PagedResult<T> { public List<T> getValues(); Any questions, please ask and I will try to advice. /Patrik
|
|
|
Re: [sculptor] pagination
by Steffen Stundzig
::
Rate this Message:
Hi,
i will code something tomorrow. The return value is always a List or Set or Bag as in my sample: Patrik Nordwall schrieb: > public class PagedResult<T> { > public List<T> getValues(); Template T is in this sample List<Planet>, but could also be Set<Planet> and so on. >> PagedResult is parameterized with the real finder result: >> ----- >> public class PagedResult<T> { >> public <T> getValues(); >> int currentPage; -- Steffen Stundzig Telefon: +49 (0) 341 / 231-0183-401 Telefax: +49 (0) 341 / 231-0183-411 Mobil: +49 (0) 151 / 173-9673-1 (!neu) http://itemis.de steffen.stundzig@... https://www.xing.com/profile/Steffen_Stundzig itemis AG Ludwig-Erhard-Straße 51 04103 Leipzig Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael Neuhaus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by PaloT
::
Rate this Message:
I understand you idea however from practice I know that from service
method you have to return not only result set but also some additional information for paging. For example total number of pages to show, or how many next pages is available for paging. Pavel On Sun, Nov 23, 2008 at 11:02 AM, Steffen Stundzig <steffen.stundzig@...> wrote: > Hi, > > what i mean is, e.g. on each findAll we could generate two findAll > methods in services and/or repositories. The first is the current one, > the second (new) contains 2 additional parameters (int firstResult, int > maxResults). So we are compatible with older versions. > > These parameters could we very simple propagated to the criteria based > FinderAccessApi-classes with criteria.setMaxResults() and so on. > > These feature is generic and should be paramterizable per > generate.pagination. > > I'm implementing it in my local sculptor-generator project and be very > appreciated if it could be in the main trunk. So the diff between the > generator branches is a little bit smaller. ;-) > > I don't know how we could implement this without hibernate but with real > JPA, but I'm sure it's possible. > > > What do you mean? > > regards > Steffen... > > Patrik Nordwall schrieb: >> Do you mean that you would like to have support for pagination in the built >> in queries, such as findAll? >> If you write your own query (access object) I don't think there is anything >> stopping you from implementing pagination. You can pass your own (non >> persistent) objects holding these parameters. Please explain more. >> /Patrik >> >> >> Steffen Stundzig wrote: >>> Hi all, >>> >>> there are any thoughts about pagination of hibernate queries in sculptor? >>> >>> We could use the criteria or the query api for that, but we need also >>> propagation of the page parameters such firstResult and MaxResults in the >>> Services and Repositories, so clients could use it. >>> >>> see >>> http://www.hibernate.org/hib_docs/entitymanager/reference/en/html/objectstate.html#d0e763 >>> hibernate reference >>> >>> regards >>> >> > > -- > Steffen Stundzig > > Telefon: +49 (0) 341 / 231-0183-401 > Telefax: +49 (0) 341 / 231-0183-411 > Mobil: +49 (0) 151 / 173-9673-1 (!neu) > > http://itemis.de > steffen.stundzig@... > https://www.xing.com/profile/Steffen_Stundzig > > itemis AG > Ludwig-Erhard-Straße 51 > 04103 Leipzig > > Rechtlicher Hinweis: > > Amtsgericht Dortmund, HRB 20621 > > Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek > > Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael Neuhaus > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Fornax-developer mailing list > Fornax-developer@... > https://lists.sourceforge.net/lists/listinfo/fornax-developer > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by Steffen Stundzig
::
Rate this Message:
Hi pavel,
you are absolutely right. If I reflect my last implementation with pagination, so I have todo 2 calls to service interface. First call is something like "select count(*) from ..." to calculate the maxPages and next was "select id,.. from". My API proposalin the other email, is it ok? I misssed something? regards Pavel Tavoda schrieb: > I understand you idea however from practice I know that from service > method you have to return not only result set but also some additional > information for paging. For example total number of pages to show, or > how many next pages is available for paging. > > Pavel > > On Sun, Nov 23, 2008 at 11:02 AM, Steffen Stundzig > <steffen.stundzig@...> wrote: >> Hi, >> >> what i mean is, e.g. on each findAll we could generate two findAll >> methods in services and/or repositories. The first is the current one, >> the second (new) contains 2 additional parameters (int firstResult, int >> maxResults). So we are compatible with older versions. >> >> These parameters could we very simple propagated to the criteria based >> FinderAccessApi-classes with criteria.setMaxResults() and so on. >> >> These feature is generic and should be paramterizable per >> generate.pagination. >> >> I'm implementing it in my local sculptor-generator project and be very >> appreciated if it could be in the main trunk. So the diff between the >> generator branches is a little bit smaller. ;-) >> >> I don't know how we could implement this without hibernate but with real >> JPA, but I'm sure it's possible. >> >> >> What do you mean? >> >> regards >> Steffen... >> >> Patrik Nordwall schrieb: >>> Do you mean that you would like to have support for pagination in the built >>> in queries, such as findAll? >>> If you write your own query (access object) I don't think there is anything >>> stopping you from implementing pagination. You can pass your own (non >>> persistent) objects holding these parameters. Please explain more. >>> /Patrik >>> >>> >>> Steffen Stundzig wrote: >>>> Hi all, >>>> >>>> there are any thoughts about pagination of hibernate queries in sculptor? >>>> >>>> We could use the criteria or the query api for that, but we need also >>>> propagation of the page parameters such firstResult and MaxResults in the >>>> Services and Repositories, so clients could use it. >>>> >>>> see >>>> http://www.hibernate.org/hib_docs/entitymanager/reference/en/html/objectstate.html#d0e763 >>>> hibernate reference >>>> >>>> regards >>>> >> -- >> Steffen Stundzig >> >> Telefon: +49 (0) 341 / 231-0183-401 >> Telefax: +49 (0) 341 / 231-0183-411 >> Mobil: +49 (0) 151 / 173-9673-1 (!neu) >> >> http://itemis.de >> steffen.stundzig@... >> https://www.xing.com/profile/Steffen_Stundzig >> >> itemis AG >> Ludwig-Erhard-Straße 51 >> 04103 Leipzig >> >> Rechtlicher Hinweis: >> >> Amtsgericht Dortmund, HRB 20621 >> >> Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek >> >> Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael Neuhaus >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Fornax-developer mailing list >> Fornax-developer@... >> https://lists.sourceforge.net/lists/listinfo/fornax-developer >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Fornax-developer mailing list > Fornax-developer@... > https://lists.sourceforge.net/lists/listinfo/fornax-developer -- Steffen Stundzig Telefon: +49 (0) 341 / 231-0183-401 Telefax: +49 (0) 341 / 231-0183-411 Mobil: +49 (0) 151 / 173-9673-1 (!neu) http://itemis.de steffen.stundzig@... https://www.xing.com/profile/Steffen_Stundzig itemis AG Ludwig-Erhard-Straße 51 04103 Leipzig Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael Neuhaus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by PaloT
::
Rate this Message:
I couldn't find your api proposal, am I overlooking something?
Just to be sure about paging. For real enterprise solutions you need two types of paging. - Where you know number of items - Where you don't know number of items Second one is important for really BIG tables with complex where clauses specially when combination of fields depends on complex GUI where you don't know which items get filled and you couldn't prepare indexes. For example Oracle can do real optimization with maxResults set in query. For second case we implemented query in special way that we looked only N (usually 2 or 3) pages forward if here is enough records. Just for curiousness, we have psychological study which state that users can't handle more than 80 records. When it doesn't fit they should specify better criteria for search. Fulltext search in database is great for such situations. Pavel On Mon, Nov 24, 2008 at 8:51 AM, Steffen Stundzig <steffen.stundzig@...> wrote: > Hi pavel, > > you are absolutely right. If I reflect my last implementation with > pagination, so I have todo 2 calls to service interface. First call is > something like "select count(*) from ..." to calculate the maxPages and > next was "select id,.. from". > > My API proposalin the other email, is it ok? I misssed something? > > regards > > Pavel Tavoda schrieb: >> I understand you idea however from practice I know that from service >> method you have to return not only result set but also some additional >> information for paging. For example total number of pages to show, or >> how many next pages is available for paging. >> >> Pavel >> >> On Sun, Nov 23, 2008 at 11:02 AM, Steffen Stundzig >> <steffen.stundzig@...> wrote: >>> Hi, >>> >>> what i mean is, e.g. on each findAll we could generate two findAll >>> methods in services and/or repositories. The first is the current one, >>> the second (new) contains 2 additional parameters (int firstResult, int >>> maxResults). So we are compatible with older versions. >>> >>> These parameters could we very simple propagated to the criteria based >>> FinderAccessApi-classes with criteria.setMaxResults() and so on. >>> >>> These feature is generic and should be paramterizable per >>> generate.pagination. >>> >>> I'm implementing it in my local sculptor-generator project and be very >>> appreciated if it could be in the main trunk. So the diff between the >>> generator branches is a little bit smaller. ;-) >>> >>> I don't know how we could implement this without hibernate but with real >>> JPA, but I'm sure it's possible. >>> >>> >>> What do you mean? >>> >>> regards >>> Steffen... >>> >>> Patrik Nordwall schrieb: >>>> Do you mean that you would like to have support for pagination in the built >>>> in queries, such as findAll? >>>> If you write your own query (access object) I don't think there is anything >>>> stopping you from implementing pagination. You can pass your own (non >>>> persistent) objects holding these parameters. Please explain more. >>>> /Patrik >>>> >>>> >>>> Steffen Stundzig wrote: >>>>> Hi all, >>>>> >>>>> there are any thoughts about pagination of hibernate queries in sculptor? >>>>> >>>>> We could use the criteria or the query api for that, but we need also >>>>> propagation of the page parameters such firstResult and MaxResults in the >>>>> Services and Repositories, so clients could use it. >>>>> >>>>> see >>>>> http://www.hibernate.org/hib_docs/entitymanager/reference/en/html/objectstate.html#d0e763 >>>>> hibernate reference >>>>> >>>>> regards >>>>> >>> -- >>> Steffen Stundzig >>> >>> Telefon: +49 (0) 341 / 231-0183-401 >>> Telefax: +49 (0) 341 / 231-0183-411 >>> Mobil: +49 (0) 151 / 173-9673-1 (!neu) >>> >>> http://itemis.de >>> steffen.stundzig@... >>> https://www.xing.com/profile/Steffen_Stundzig >>> >>> itemis AG >>> Ludwig-Erhard-Straße 51 >>> 04103 Leipzig >>> >>> Rechtlicher Hinweis: >>> >>> Amtsgericht Dortmund, HRB 20621 >>> >>> Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek >>> >>> Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael Neuhaus >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Fornax-developer mailing list >>> Fornax-developer@... >>> https://lists.sourceforge.net/lists/listinfo/fornax-developer >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Fornax-developer mailing list >> Fornax-developer@... >> https://lists.sourceforge.net/lists/listinfo/fornax-developer > > -- > Steffen Stundzig > > Telefon: +49 (0) 341 / 231-0183-401 > Telefax: +49 (0) 341 / 231-0183-411 > Mobil: +49 (0) 151 / 173-9673-1 (!neu) > > http://itemis.de > steffen.stundzig@... > https://www.xing.com/profile/Steffen_Stundzig > > itemis AG > Ludwig-Erhard-Straße 51 > 04103 Leipzig > > Rechtlicher Hinweis: > > Amtsgericht Dortmund, HRB 20621 > > Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek > > Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael Neuhaus > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Fornax-developer mailing list > Fornax-developer@... > https://lists.sourceforge.net/lists/listinfo/fornax-developer > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by Patrik Nordwall
::
Rate this Message:
I had a look at this conversation again. JPA (and hibernate) has support for setFirstResult and setMaxResult. Do we really need something more complicated than that?
I can easily add optional support for those two parameters in queries such as findAll, findByCriteria, findByQuery. /Patrik
|
|
|
Re: [sculptor] pagination
by Steffen Stundzig
::
Rate this Message:
hi patrik,
yes i know these parameters. In the old (no JPA) hibernate usage i use the criteria api which has support for first and max result since many years. But what I need as parameters are - first page - page size and as result I need a result object, something like - FindResult<Planet>() with - List<Planet> getValues() - int maxNumberOfPages - int pageSize So we have something more then only two parameters to add. Do you need paging now? regards Patrik Nordwall schrieb: > I had a look at this conversation again. JPA (and hibernate) has support for > setFirstResult and setMaxResult. Do we really need something more > complicated than that? > > I can easily add optional support for those two parameters in queries such > as findAll, findByCriteria, findByQuery. > > /Patrik ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by PaloT
::
Rate this Message:
We need also support for "order by" and criteria. I know we have
findByCriteria but maybe findAll should be generated more like findByCriteria plus paging plus order by. Regards Pavel ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by Steffen Stundzig
::
Rate this Message:
thanks pavel,
i've implemented all this stuff in our 1.5.0-snapshot based customer project. If I find some time, i'll port it to 1.7.0? regards Pavel Tavoda schrieb: > We need also support for "order by" and criteria. I know we have > findByCriteria but maybe findAll should be generated more like > findByCriteria plus paging plus order by. > > Regards > > Pavel > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Fornax-developer mailing list > Fornax-developer@... > https://lists.sourceforge.net/lists/listinfo/fornax-developer ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by Patrik Nordwall
::
Rate this Message:
"Order by" is actually supported, but one of my team mates found a bug in the jpa impl of FindAll today CSC-425. I will fix that asap. It should be ok for FindByCriteria. Usage: Repository PlanetRepository { findAll; findAll(String orderBy); } asc/desc is also supported: findAll(String orderBy, boolean orderByAsc); I realized that those optional parameters of the access objects are maybe a hidden secret. If you look in the FindAllAccess interface you see extends Ordered, which defines methods setOrderBy, setOrderByAsc. Parameters of repository operation with corresponding names are used and invokes the setters of the access objects. In this way it is possible to support optional parameters in any combination. Pretty cool :-) /Patrik |
|
|
Re: [sculptor] pagination
by Steffen Stundzig
::
Rate this Message:
hi,
sounds cool, but what we need was an FilterObject which could be created and managed at runtime in the frontend. These filterobject contains the current filters and also the current sort criterias, which also works over associations, which could be chaanged by the user at runtime. regards Patrik Nordwall schrieb: > > PaloT wrote: >> We need also support for "order by" and criteria. I know we have >> findByCriteria but maybe findAll should be generated more like >> findByCriteria plus paging plus order by. >> > > "Order by" is actually supported, but one of my team mates found a bug in > the jpa impl of FindAll today CSC-425. I will fix that asap. It should be ok > for FindByCriteria. > > Usage: > Repository PlanetRepository { > findAll; > findAll(String orderBy); > } > > asc/desc is also supported: > findAll(String orderBy, boolean orderByAsc); > > > I realized that those optional parameters of the access objects are maybe a > hidden secret. If you look in the FindAllAccess interface you see extends > Ordered, which defines methods setOrderBy, setOrderByAsc. > Parameters of repository operation with corresponding names are used and > invokes the setters of the access objects. In this way it is possible to > support optional parameters in any combination. Pretty cool :-) > > /Patrik > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by Patrik Nordwall
::
Rate this Message:
Ok, so the difference is that in the response you get a count of how many values there are in total (but in pages). Do you execute an extra count query each time? I suggest that our access objects (FindAll, FindByQuery, FindByCriteria) support firstResult and maxResult, since that is simple and something that developers recognize from JPA/Hibernate. We can also add a CountAll access object. Thereafter we add other built in repository operations pageableFindAll, pageableFindByQuery, pageableFindByCriteria, which use the mechanisms of firstResult, maxResult and count, but expose another API, with the paging objects you suggest. I can do an attempt with pageableFindAll and you can review the implementation before we continue with more. Steffen, can you send me a code example of your implementation, or anything you think is useful. /Patrik |
|
|
Re: [sculptor] pagination
by PaloT
::
Rate this Message:
Nice how far and fast we should go. My question is if we need support
for NOT paging functions. When page parameter is null we should return all results. When paging parameter is filled we should follow it. Only reason for keeping no paging interface is backward compatibility but we can break it with new version, can't we? Pavel On Mon, Oct 12, 2009 at 8:56 PM, Patrik Nordwall <patrik.nordwall@...> wrote: > > > > Steffen Stundzig wrote: >> >> yes i know these parameters. In the old (no JPA) hibernate usage i use >> the criteria api which has support for first and max result since many >> years. >> >> But what I need as parameters are >> - first page >> - page size >> >> and as result I need a result object, something like >> - FindResult<Planet>() >> >> with >> - List<Planet> getValues() >> - int maxNumberOfPages >> - int pageSize >> >> So we have something more then only two parameters to add. >> > > Ok, so the difference is that in the response you get a count of how many > values there are in total (but in pages). Do you execute an extra count > query each time? > > I suggest that our access objects (FindAll, FindByQuery, FindByCriteria) > support firstResult and maxResult, since that is simple and something that > developers recognize from JPA/Hibernate. > > We can also add a CountAll access object. > > Thereafter we add other built in repository operations pageableFindAll, > pageableFindByQuery, pageableFindByCriteria, which use the mechanisms of > firstResult, maxResult and count, but expose another API, with the paging > objects you suggest. > > I can do an attempt with pageableFindAll and you can review the > implementation before we continue with more. Steffen, can you send me a code > example of your implementation, or anything you think is useful. > > /Patrik > > -- > View this message in context: http://www.nabble.com/-sculptor--pagination-tp20636538s17564p25861179.html > Sent from the Fornax-Platform mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Fornax-developer mailing list > Fornax-developer@... > https://lists.sourceforge.net/lists/listinfo/fornax-developer > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fornax-developer mailing list Fornax-developer@... https://lists.sourceforge.net/lists/listinfo/fornax-developer |
|
|
Re: [sculptor] pagination
by Patrik Nordwall
::
Rate this Message:
I think we should support both variants, not only for backward compatibility. Some domain objects are known to be few, and paging is not needed, then you would not complicate things. I'm not talking about generated crud gui. /Patrik |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
