Paginierung: Richtige Seite eines Datensatzes finden

Hallo,

ich habe hier ein ziemlich nerviges Problem, für das ich noch keine gute
Lösung
gefunden habe.

Wie kann ich, wenn ich nur die Datensatz-Id zur Verfügung habe,
herausfinden,
auf welcher Seite einer Paginierung sich der Datensatz befindet?

Viele Grüße

Michael K.

Hallo Michael,

wenn du das nur ab und an verwendest, koenntest du diese Methode in
ein Modul packen, dass du in all deinen Modellen includest (ich gehe
davon aus, dass du will_paginate verwendest):

def page_number
page = 1

while true
  objects_on_page = self.class.paginate :page => page, :order =>

‘created_at DESC’

  if objects_on_page
    return page if objects_on_page.include?(self)
  else
    return -1
  end

  page += 1
end

end

Das geht wahrscheinlich noch eleganter, aber die Page findest du so
auf jeden fall raus.

  • Johannes

2008/10/29 Michael K. [email protected]:

Hallo Johannes,

vielen Dank für Deine Idee. So ähnlich habe ich das auch schon für kleine
Tabellen gelöst. Im aktuellen Fall betrifft es allerdings ein paar tausend
Datensätze. Da ist dann so eine Schleife keine so gute Lösung.

Viele
Grüße
Michael

Johannes Fahrenkrug schrieb:

Hallo Jens,

eleganter wäre
schön.
Darum geht’s: Der Nutzer erhält als Ergebnis einer Produktsuche eine
Ergebnisliste von Produkten. Er kann eines der Produkte anklicken und
gelangt
zur Detailseite. Und von dort soll er die Möglichkeit haben zu “normalen”
Produktliste mit der entsprechenden Seite zu navigieren (nicht zurück zur
Produktsuche).

Das Problem besteht darin, daß der Nutzer über die Suchergebnisliste auf die
Detailseite gelangt und nicht über die paginierte Standardliste. Sonst wär’s ja
einfach :wink:

Viele
Grüße
Michael

Johannes Fahrenkrug schrieb:

Hallo Michael,

keine Ahnung, ob das sinnvoll ist, aber ich würde Folgendes probieren
(im Detail sicher nicht trivial):

  • Bei jedem paginierten Model-Zugriff cached Du für alle geladenen
    Objekte die Seite, auf der sie erscheinen (schön transparent in einer
    paginierten find-Methode verpackt)
  • Wenn Du jetzt die Paginierungs-Seite zu einem Objekt wissen willst,
    schaust Du im Cache nach
  • Wenn das Objekt (die ID) im Cache ist, überprüfst Du, ob’s (noch)
    stimmt
  • Falls nicht, gehst Du Seitenweise nach vorne und hinten (dabei
    werden weitere Objekte im Cache aktualisiert)
  • Wenn das Objekt nicht im Cache ist, suchst Du es, wie in den anderen
    Mails schon beschrieben (auch dabei werden weitere Objekte im Cache
    aktualisiert)

Auf diese Weise suchst Du nur so viel, wie nötig und der Such-Aufwand
wird auf mehrere Anfragen verteilt. Und je mehr Aufrufe Du hast, desto
genauer ist Dein Cache. Und der Cache ist klein (nur ID-Seiten-
Zuordnungen). Im Zweifel kannst Du im Hintergrund auf einer anderen
Maschine den Cache dauernd erneuern.

Sicher recht aufwändig… naja… klingt aber nach einem interessanten
Problem… bin gespannt, wie Du’s letzten Endes löst… :smiley:

Grüsse, Niko.

Hallo Michael,

das stimmt natuerlich!
Wozu brauchst du das denn ueberhaupt? Vielleicht kann man das ja
eleganter loesen.

  • Johannes

2008/10/29 Michael K. [email protected]:

Hi,
IMHO brauchst Du den count, und die Position des Datensatzes im
Resultset.
Um dann mit dem Offset und Limit die richtige Seite zu öffnen.

Vielleicht hilft Dir dieser Thread:
http://forums.mysql.com/read.php?20,126556,126556#msg-126556

Google-Suche: find, position, resultset, mysql (wenn Du überhaupt mysql
benutzt)

Besten Gruß

Jan

Am 29. Oktober 2008 14:23 schrieb Michael K.
[email protected]:

Das Problem besteht darin, daß der Nutzer über die Suchergebnisliste auf

Hallo Michael,

objects_on_page = self.class.paginate :page => page, :order =>

end

ich habe hier ein ziemlich nerviges Problem, für das ich noch keine

[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug


rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug


Jan P.
Rechtsanwalt

Babendiekstraße 60 B
22587 Hamburg
Tel +49 (0)40 41265809 Fax +49 (0)40 380178-73022
Mobil +49 (0)171 3516667

Hi,

Am 29.10.2008 um 14:44 schrieb Jan P.:

IMHO brauchst Du den count, und die Position des Datensatzes im
Resultset.
Bin mal davon ausgegangen, dass das nicht gegeben ist… sonst ist’s -
triv- äh… lösbar. :wink: Die Position im Resultset ist ja genau der
Punkt… aber zugegebener Maßen fällt’s mir gerade schwer mir ein
Szenario auszumalen, wo man das nicht hat… oder vielleich doch: Wenn
das Resultset z.B. das Ergebnis einer Ferret-Suche ist… ist hier aber
wohl nicht der Fall, oder? … well… :smiley:

Niko.

Genau, um die Position im Resultset zu finden, hilft ihm der Thread.
Wenn ich es richtig verstanden habe, hat er den Resultset der aktuellen
Suche, aber nicht jenen aus der allgemeinen Produktliste (wahrscheinlich
ohne conditions und order by)

Gruß

Jan

Am 29. Oktober 2008 14:52 schrieb Niko D. [email protected]:

Ergebnis einer Ferret-Suche ist… ist hier aber wohl nicht der Fall, oder? …
well… :smiley:

Niko.


rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug


Jan P.
Rechtsanwalt

Babendiekstraße 60 B
22587 Hamburg
Tel +49 (0)40 41265809 Fax +49 (0)40 380178-73022
Mobil +49 (0)171 3516667

Erstmal vielen Dank an alle, die Tips gegeben haben. So einfach
scheint’s ja
nicht zu sein.

Ich bin etwas verdutzt, daß es die Problemstellung so selten vorkommt.
Hmm, muß
ich mal weiter drüber brüten.

Falls mir was einfällt, werd’ ichs hier verlautbaren.

Viele Grüße

Michael K.

Jan P. schrieb:

Michael K. schrieb:

Erstmal vielen Dank an alle, die Tips gegeben haben. So einfach
scheint’s ja nicht zu sein.

Wäre es nicht eine Alternative, die URL zu der Seite, von der man
gekommen ist, als Parameter an die Detailseite weiterzugeben?

Ungefähr so:
path/to/detail/1?return_to=path/to/result

Dieser Parameter steht dann unter params[:return_to] zur Verfügung und
könnte zum erzeugen des Links auf der Detailseite verwendet werden.

Zur Sicherheit sollte man den Parameter allerdings mit einem geeigneten
Verfahren ver- und entschlüsseln, damit keine fremden oder boshaften
Links übergeben werden.

Hope this helps,
Sebastian

Hallo Sebastian,

Sebastian Roebke schrieb:

Michael K. schrieb:

Erstmal vielen Dank an alle, die Tips gegeben haben. So einfach
scheint’s ja nicht zu sein.

Wäre es nicht eine Alternative, die URL zu der Seite, von der man
gekommen ist, als Parameter an die Detailseite weiterzugeben?

Ungefähr so:
path/to/detail/1?return_to=path/to/result

Das verstehe ich jetzt nicht. Der Nutzer kommt ja von der Seite mit den
Suchergebnissen. Ich brauche aber einen Link von der Detailseite zu der
paginierten Seite der Standardliste.

Viele Grüße

Michael K.

Hi!

Zitat von Michael K. [email protected]:

Wäre es nicht eine Alternative, die URL zu der Seite, von der man
gekommen ist, als Parameter an die Detailseite weiterzugeben?

Das verstehe ich jetzt nicht. Der Nutzer kommt ja von der Seite mit den
Suchergebnissen. Ich brauche aber einen Link von der Detailseite zu der
paginierten Seite der Standardliste.

Alles klar, dann hatte ich nicht aufmerksam genug gelesen. Sorry :wink:

Hier habe ich leider auch keine besseren Ideen.

Viele Grüße,
Sebastian

On Friday 31 October 2008, Michael K. wrote:

Das verstehe ich jetzt nicht. Der Nutzer kommt ja von der Seite mit
den Suchergebnissen. Ich brauche aber einen Link von der Detailseite
zu der paginierten Seite der Standardliste.

Dafür gab es doch von Jan P. schon einen Link auf eine Erklärung. Du
musst die Suchkriterien (also :conditions und :order) für die
Standardliste nehmen und zählen (#count bzw. SQL COUNT(*)), wieviele
Zeilen vor dem aktuellen Datensatz kommen. Falls Assoziationen, und
dadurch left outer joins, beteiligt sind, hilft vermutlich GROUP BY.

Zeig doch mal ein konkretes Beispiel, dann kann man dir auch helfen.

Michael

Ich habe doch garnicht geschrieben, daß ich die Lösung von Jan nicht
verwende.

Mein Antwort bezog sich nicht auf die von Jan vorgeschlagene Lösung,
sondern auf
den Vorschlag, die Rücksprung-URL als Parameter beizubehalten.

Ist doch alles ok.

Viele Grüße

Michael K.

Michael S. schrieb: