I have a website which its admin user logs into a restricted area and adds content that is displayed on the public area. The admin wants a simple input text field on the post insert/edit form where he can type a number that determines in which position that post will be displayed to the public.
So, if the “Foo” post is given the number 3, it should be listed in the 3rd position, the old post 3 should become 4, 4 should become 5, and so on. If post 5 is repositioned to 1, 1 should automatically become 2, 2 should become 3, etc. If the admin reposition, 3 to 2, 2 should just become 3 without the need to change the other ones. If 10 becomes 9, 9 becomes 10 and no need to change other posts' position either. In short, when the position of one single post is changed (or inserted in the middle of existing posts), the remaining posts should have their position shifted accordingly.
I have considered two possibilities:
create a crazy algorithm that selects each post needed and updates the position column;
implement a linked list in the table so that each post always knows what is the primary key of the next one.
With the first option, when the admin inserts or updates a post's position, all the work is done at that moment, and when the public site is visited, the SQL just selects all the needed posts in a single query and order them by position. I don't really know yet how I would implement it, but I'm sure using a lot of code and possibly bad trade-offs it would be possible.
With the second option, there is much less work done during the insert/update, but when users access the site, I need to do one select for each post so that the right positioning can be achieved using the each post's link to the next “node”. So, if I have 150 posts in a given category, I'll have to run 150 selects (one for each post that is pointed to by the current "node". No pagination will be used in this case, and only the titles will be really listed, one below the other, so, I will really list them all.
I would like suggestions to other approaches, insights or improvements on the two possibilities I have described.
SOLUTION
I accepted #FractlizeR answer because it uses some other established piece of software to support his choice.
I wrote a small prototype on the solution I ended up using at work. Of course the code I used at work is different because I was changing a legacy system. Still, I used exactly the same SQL approach as the ones in the prototype. I hope I can improve that prototype and specially its comments soon, but at least it is there in case I or someone else needs to do something similar.
I would vote for #1. This is what, for example, XenForo forum engine does. It uses post position for paging and other things. When it needs to insert a new post into a thread, it queries thread for all posts, that needs to be reordered, then for each post calculates a new position and then updates table for all posts, which position changed.
We use XenForo for a long time in production and actually there should be no problems involved since this operation (reorder) is not so complex.
Related
I can't seem to find any information how it would be best to put data inside a component. To define the problem, lets say we have a user table in a database and this table has an ID and maybe 30 fields with details about the user.
Now if I want to create a Vue component that shows a list of many users details, lets just call it <user-details>. To show this on a page, would you:
1) Call the database to get all users you want to show and get their ID, then do a for loop with <user-details id="xxx"> and make Vue do ajax call to some API and get the details?
2) OR, use the inline version <user-details id="xxx" name="user name" ...> with 30+ fields?
3) OR, have some specific Vue component for this user list, maybe it's users who did not validate email or something, then <users-not-validated> and use ajax?
The problem I see is, that in case 1, you already called the database for the IDs, then call the database once again with ajax with pretty much the same SQL.
In case 2, it's just annoying to fill so many fields out each time you use the component.
In case 3, you will end up with a TON of components...
How do you approach this?
You won't find such information because it's not Vue related. Vue doesn't care what you use it for and how you structure your data. It aims to allow you to do anything you want.
Just as it doesn't care what your folder structure looks like (because, at its core, all it needs in order to render is a single DOM element), it also doesn't care how you organize your API, how you structure your application, your pages or even your components.
Obviously, having this amount of freedom is not always a good thing. If you look around, you'll notice people who use Vue professionally have embraced certain patterns/structures which allow for better code reuse and more flexibility. Nuxt is one such good example.
To anyone just starting with Vue, I recommend trying to use Nuxt as soon as possible, even if its overkill for their little project because they will likely pick up some good patterns.
Getting down to your specific question, in terms of data API architecture, you always have to ask yourself: what's the underlying principle?
The underlying principle is to make your application as fast as possible. In order to do that, ideally, you want to fetch exactly how much data you want to display, but not more. Therefore:
when getting the same data, if you have a choice, always try to lower the number of requests. You don't want each item in the list to initiate a call to the server when it is rendered. Make a single call for the entire list (only fetching what you display in the list view) and call for details if the user requests it (presses the details button).
adjust your pagination to cater how many items you can display on a screen, but also according to how long it takes to load a page. If it takes too long, lower the pageSize and allow your items more padding. If you think about it, most people prefer a snappy app with fewer items on page (and generously padded items) to one which takes seconds to load each page and displays items so crummed they're hard to click/tap on or hard to follow in the list without losing the row.
However, you have to take these guidelines with a grain of salt. In the vast majority of cases fetching full data in one call makes little to no difference in user experience. Many times the delays have to do with server cold-starts (first call to a server takes longer, as it needs to "wake it up" - but all subsequent calls of the same type are faster), with unoptimized images or with bad internet connectivity (as in, it works poorly regardless of whether you receive only the names or the full list of details).
Another aspect to keep in mind is that getting all the data at once is a trade-off. You do get a slower initial call but afterwards you are able to do seamless animations between list view and detail view as the data is already fetched, no more loading required. If you handle the loading state graciously, it's a viable option in many scenarios.
Last, but not least, your 2nd point's drawback does not exist. You can always bind all the details in one go:
<user-details v-bind="user" />
is equivalent to
<user-details :id="user.id" :name="user.name" :age="user.age" ... />
To give you a very basic example, the typical markup for your use-case would be:
<div v-if="isLoadingUsers" />
<user-list v-else :users="users">
<user-list-item v-for="(user, key) in users"
:key="key"
v-bind="user"
#click="selectedUser = user" />
</user-list>
<user-details-modal v-bind="selectedUser" />
It's obviously a simplification, you might opt to not have a user details modal but a cool transform on the list item, making it grow and display more details, etc...
When in doubt, simplify. For example, only showing details for one selected item (and closing it when selecting another) will solve a lot of UI problems right off the bat.
As for the last question: whether or not to have different components for different states, the answer should come from answering a different question: how large should you allow your component to get? The upper limit is generally considered around 300 lines, although I know developers who don't go above 200 and others who don't have a problem having 500+ lines in a component).
When it becomes too large, you should extract a part of it (let's say the user-not-validated functionality into a sub-component) and end up with this inside the <user-detail> component:
<user-detail>
... common details (title, description, etc...)
<div v-if="user.isValidated">
...normal case
</div>
<user-not-validated v-bind="user" v-else />
... common functionality (action bar, etc...)
</user-detail>
But, these are sub-components of your <user-detail> component, which are extracted to help you keep the code organized. They shouldn't replace <user-detail> in its entirety. Similarly, you could extract the user-detail header or footer components, whatever makes sense. Your goal should be to keep your code neat and organized. Follow whatever principles make more sense to you.
Finally, if I had to single out one helpful guideline when taking code architecture decisions, it would definitely be the DRY principle. If you end up not having to write the same code in multiple places in the same application, you're doing it right.
Hope you'll find some of the above useful.
I believe I have a found a very good and fast solution for efficiently counting page views:
Working example in go playground here: https://play.golang.org/p/q_mYEYLa1h
My idea is to push this to the database every X minutes, and after pushing a key then delete it from the page map.
My question now is, what would be the optimal way to ensure that this isn't abused? Ideally, I would only want to increase page count from the same person if there was a time interval of 2 hours since last visiting the page.
As far as I know, it would be ideal to store and compare both IP and user agent (I don't want to rely on cookie/localstorage), but I'm not quite sure how to efficiently store and compare this information.
I'd likely get both the IP (req.Header.Get("x-forwarded-for")) and UserAgent (req.UserAgent()) from http.Request.
I was thinking making a visitor struct similar to my page struct that would look like this:
type visitor struct {
mutex sync.Mutex
urlIPUAAndTime map[string]time
}
This way should make it possible to do something similar to before. However, imagine if the website had so many requests that there would be hundreds of millions of unique visitor maps being stored, and each of these could only be deleted after 2 (or more) hours. I therefore think this is not a good solution.
I guess it would be ideal/necessary to write to and read from some file, but not sure how this should be done efficiently. Help would be greatly appreciated
One of optimization ways is to add a Bloom filter before this map. Bloom filter is a probabilistic structure which can say one of these:
this user is definitely new
and this user possibly was here
This is a way to cut off computation on early stage. If many of your users are new then you save requests to database to check all of them.
What if structure says "user is possibly non-unique"? Then you go the database and check it.
Here's one more optimization: if you do not need very accurate information and can agree with mistake about several percent, you may use the sole bloom filter. I guess many large sites use this technique for estimation.
hi folks,
We use StormCrawler with elasticsearch to make an index of our homepage which consist of "old pages" and "new pages".
My Question in short:
If two pages A(old),B(new) link to page X, how to pass metadata from B to X?
My Question in long:
We relauched our homepage step by step. So at time we have pdf-Files which are reachable via only the old html-pages, via only the new html-page or on both ways.
For "order by" purpose we must mark all pdf-Files which are reachable by the new html-pages.
So we insert "newHomepage=true" to seeds.txt and "metadata.transfer/-newHomepage" to "crawler-conf.yaml": Fine :-)
But for the pdf-Files which are reachable from old !and! new html-pages, we now have a race condition: If our pdf-File is "DISCOVERED" from an old page this information (newHomepage=false) is in Status-Index and can not be overridden.
( StatusUpdaterBolt does not override documents, IndexerBolt does override by default).
To make the thinks more complicate: in our case a URL (at html-page) to a PDF is redirected two times, before the file is delivered.
So from my point of view we have two possibilities:
Start the crawler two times. First we only index our new pages (and all reachable pdf files), second we index our old pages.
--> Problems with new pages which are changed after crawler was started
Store "outbound_links" and use them to set "newHomepage" independently from the crawler
--> short times with wrong metadata in index
Any advice or other ideas?
Best regards
Karsten
thanks for sharing your problem and great to hear that you are using SC. This is an interesting and unusual use case.
Your analysis of the problem is correct. An intuitive approach would be to extend the default StatusUpdaterBolt so that it updates the metadata if a document already exists. You'd need to remove the part that does the check on whether the doc has a status of DISCOVERED.
This would slow things down, but since you are dealing with a single website, this should not have a massive impact.
You could push the logic even further by setting a new nextFetchDate if the document had been fetched so that it gets refetched and updated quicker in the doc index (as opposed to the status one).
So I realize that this question can be seen as somewhat vague, but it's actually quite specific.
I started to write this out, then realized that lack of specific verbiage makes it sound vague. So let me put it this way.
I've got an Order object, that has customer data on it. It also has, for the sake of this example, a single order for a car.
The Car has a Category, Product, Year, Color. For the sake of this example, my Order page has 4 drop downs, which cascade one to another. Category populates Product populates Year populates Color.
(I was going to go with Make and Model, then realized using "Model" was getting confusing, haha.)
I've got several problems:
I've got multiple layers of dropdowns. Four, not just one.
My drop down objects are not related to each other specifically - that is to say, I use an id from Cateogry to populate Products, but Category does not come with Products when it's retrieved. This is different than the Cart example that KO has on their website.
I am stuck with the above architecture. I need to change a drop down, then send a service call to get the next drop down based on the selected drop downs id. I can't alter the service layer to nest the objects together.
My Order comes with child objects to indicate Make, Model, Year, Color. However, since these are different, I've been using the knockout.mapping keyed array and a custom binding handler to look up data object. Thankfully I only have to do this once, as after the object in the top level is replaced, it's fine.
I've been trying to use knockout.mapping to map the relevant objects, especially considering the key thing.
However, I'm totally open to just making the objects in knockout.
The problem I'm having, and this thing has really turned into a disaster, is that since everything is asynchronous, it's very difficult to resolve things in the proper order, aside from nesting within nesting within nesting.
Hence my question - I'm getting to the point where it seems like ditching knockout completely is the answer here, which doesn't seem right. It feels like I'm very close but it still doesn't work properly. (Often things load in the wrong order.) Unfortunately I can't really post the code because it's huge.
The thing is, it seems like it shouldn't be this hard. It feels like I'm missing a fundamental design pattern for knockout and drop down combos. Looking at the cart example, I'm starting to suspect that multi-layer cascading drop downs are just not feasible in knockout at the moment unless the data is all loaded ahead of time.
Am I actually missing the design pattern? If so, please elucidate. If not, go ahead and say so. I guess whichever more people agree with will be accepted.
Update
I realized after the first comment I got that I did not discuss much about some of the solutions I've tried.
So, basically yes, I've tried subscribing to the change event. I should emphasize that at the beating heart of this problem lies the fact that all of our calls to load these dropdowns are network calls.
The problem that happens is that the change event fires multiple times - once when you load the drop down, and again when the value is bound to the drop down. At least, that's been my experience.
What ends up happening is that any subscription will then fire multiple times. When it does, it causes the load to happen multiple times. Aside from the fact that I don't want to fire multiple times, there are often issues where the drop downs will get loaded incorrectly. My guess is that one of the times arrived "out of order" than the others.
I've gotten similar results with my various efforts. It really does seem to be pushing me toward some hackish stuff, like nesting 5 or 6 or 7 network calls inside of each other's callbacks. And it seems like there must be a better way.
I've tried computed observables to similar effect. I've tried loading things once via the MVC viewbag, etc. Every time I try something, I'm stymied by either something loading weird, the knockout.mapping plugin behaving strangely (it apparently will not add its key/mapping functions to existing knockout observables) or just ... some other weird issue.
Again, I ask, is this something knockout is simply incapable of? Is our situation just too peculiar? Or am I missing some method or function or object that would make all of this work?
Knockout subcribe event will solve your problem.. Its not too complicate I think..
If you think its complicate add a fiddle or code block.
I'm working on a website with a major social networking component.
I want the short username display (1 icon (maybe 2) + a styled username) to indicate:
presence (active, idle, away, offline) - font weight
avatar (autogen or uploaded) - 16x16px prefixed icon
explicit relationship to current user (followee, follower, mutual friend, FOAF, none) - hue?
implicit relationship to current user (scalar based on level of interaction) - saturation?
predicted match (multiscalar based on AI) - replaces avatar icon?
More info and details will be in a tooltip. This core part will be displayed all over the place (think e.g. the styling of usernames in StackOverflow comments, not in post signatures), and therefore needs to be compact and elegant. It doesn't need to show these data perfectly - that's what the tooltip is for - but it should give at least a subtle indication.
"Explicit relationship" means Facebook/Twitter-type "friending". This is more a permissions thing than a real "relationship" one per se.
One security feature it gives is to help prevent someone from trying to fool you with a username that looks similar to one of your friends' - you'll notice that they are implicitly colored as unrelated to you. Explicit status also affects what actions are available in the tooltip (e.g. you can't friend a friend, or poke a non-friend).
"Implicit relationship" means e.g. the difference between the 2 people you talk to all the time, the 10 you have regular contact with, the 50 you listed as your "friend" but never talk to, and the 50 you don't (yet) list as your "friend" but have talked to.
"Predicted liking" is the output of a very complex backend AI, à la OKCupid's "match score"; its purpose is to gently nudge you towards talking to people you'll probably like more. In the zero-knowledge-about-you case, it reduces to a Slashdot-style "objective" karma rating. I may also want to display some semi-categorical hints, like whether the AI thinks you'll find this person 'funny' vs 'interesting'.
How can I indicate indicate the things above in a maximally graceful way?
It might not be a good idea to show so many things at once in the small amount of space you will probably allocate to the display of the username. I think, at best you can show 3-4 things at once without confusing the user. More than that, and the user will be confused as to what is what. The task of remembering will defeat all usability aspects.
Another way to show all the stuff would be using a popup-like thing, but even that is not a good idea for the amount of information that you want to show :( I think you will probably be better off if you can simplify the problem so that you end up with fewer variables.