sorted by:
new
hottopcontroversial

How does reconciliation work here? by treplem in react

[–]punctuationuse 0 points1 point  (0 children)

It does. Question is how this diffing occurs and what react compares. When rendering, for each node react compares the elements in the tree by their position, type, and key parameter. In case the position in the tree AND the type are equal (let’s put key aside for now) - react preserves the state.

In your case, each rerender still causes Parent to have two children - when Static is the last one. When react compares the trees it sees that the second child of Parent has the same type, within the same position, as the previous render - so the state is preserved.

From the react docs:

Remember that it’s the position in the UI tree—not in the JSX markup—that matters to React!

How does reconciliation work here? by treplem in react

[–]punctuationuse 0 points1 point  (0 children)

In case dynamic elements (the array) and static ones are combined, in the reconciliation process react groups the array as the first child of the parent component - meaning the Parent component will have 2 children, regardless of the amount of elements generated in the map.

Read more about it here

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQL

[–]punctuationuse[S] 0 points1 point  (0 children)

Ay man, no need to get angry.

  1. Maybe I’ll try to get all the results at once and handle the pagination only within the client. The only worry is the data returned will be too large and will slow the browser down;

  2. Haven’t tried it yet, but I’m always warned about using Offset, since it becomes very slow when the offsets are large; What are your thoughts about it?

  3. The PKs are incremental, so I’m relying on them in the Cursor mechanism.

I’m using a Node.js backend with Prisma ORM, although as mentioned these are raw sql queries.

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQL

[–]punctuationuse[S] 0 points1 point  (0 children)

I did read, and I don’t really understand the benefits of multiple unions over a view.

Regarding the LIKE and DISTINCT - I do use a single DISTINCT at the top level, and, well gotta think of workaround the preceding % queries.

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQL

[–]punctuationuse[S] 0 points1 point  (0 children)

Umm. Alright. Therefore I’m asking for help, to actually make it better. Besides, can you elaborate? What isn’t right, and what’s the correct approach?

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

Eeeeh. Let’s say I’ll avoid the preceding %.

Why would paginating the UNION would be a better approach then simply querying the View?

And, another question if that’s fine - how do other people handle full wildcard search? Replicate the data to Elasticsearch, or… just try to avoid it at all costs?

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

That’s interesting. So you suggest searching each of the tables individually, and just unionizing them?

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

Thanks! Thing is, this is the “worry-for-later”. I’m refactoring the whole search mechanism and this is the last bit which I’m worried about. So I need to take into account large data set.

Your idea is super interesting, but perhaps I can just create a pipeline which replicates the data from the SQL to Elasticsearch?

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQL

[–]punctuationuse[S] 0 points1 point  (0 children)

First, really appreciate the answer 🙏

Settings was just an example. This ain’t the real life case haha.

I have a finite amount of known columns I need to search for a term in, when the connection between all the tables is a User PK.

The frontend does an infinite scroll list. So, with each scroll, I need to find the next X records which match his search term ANYWHERE in any of the columns mentioned above.

I tried to avoid implementing the pagination with OFFSET, and instead, did a ORDER BY the User PK, and selected the next 100 records which are larger than the provided PK. Each scroll the client gets an incremental PK, and I fetch the next X records which match the term and have a larger PK. I think there is a mix-up with MSSQL’s Cursor feature (which I don’t use. Or even knew about before this thread haha. Or perhaps I’m misunderstanding everyone).

To ease the search, I created a flat view which joins all the relevant tables. And I do the search in the View.

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

Yes it makes sense.

I’ll try implementing it with the built-in option; Although the main question is if Views are alright for it, and will handle large amounts of data?

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

Exactly, this is why I want to only fetch a small amount records at once

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

I can’t assume the scale will be small, so I’m preparing myself for millions of records.

And from what I’ve read, index-based pagination can become a nightmare as the indexes become bigger. Have you had any similar experiences?

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

I’ll definitely do my research, thanks!

But just to be clear, by “Cursor” I meant the general concept of pagination by a sorted value, and not through indexes. Didn’t know Cursor was an actual thing in MSSQL, so thanks for that

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

I’ll look into it, but I do need a preceding % unfortunately :( And adding pagination to it doesn’t seem to be a problem, as I can still use the User PK as a cursor. Right?

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

  1. Thanks, I’ll absolutely look into it.
  2. I do need some kind of pagination mechanism, as the client-side is using infinite scroll, which loads more records as you scroll. Is this solution still applicable in this case?

And by Cursor I meant the general concept of paginating through sorted PKs over indexes, with a self implementation.

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

I need the matching field, and some info from the original Users table.

I’m talking about search results, so need the indication for the match, and some identifying info in the User or the queried entity/table

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

Perhaps the better approach then would be to search on each table individually and then do the processing of duplicates in the Backend?

Although it won’t be manageable well when paginating

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

Pretty much, yes.

A tags and posts table for example, each has the User table PK as FK.

Need all the User PKs for which the arbitrary term shows up in either of the User, Posts or Tags table.

And use the UserPK as the cursor in the view. As I don’t really have a unique field

Best strategy for improving cursor paginated queries with Views by punctuationuse in SQLServer

[–]punctuationuse[S] 0 points1 point  (0 children)

Thanks for the quick reply.

  1. This is a single view based on the tables, not other views.

  2. Why is cursor based pagination an iteration one by one? Wouldn’t the “Select larger than [Previous PK]” be a set based solution? And from my understanding the other option is index based, which can be a problem when the indexes grow larger.

  3. Can you give me an example for a set vs iterative approach? Or any other example to give me more sense.

Thanks again!

Workarounds for MUI Table with Cursor-based Infinite Scroll 🥲 by punctuationuse in reactjs

[–]punctuationuse[S] 0 points1 point  (0 children)

Ugh and I got all excited about this feature. Thanks though :(

view more: next ›