[Suggestion] Allow us to see the last login of LS members

[FinagleABagel]

No, but database queries aren't some big industry secret.

Please read. Obviously DB queries aren't secret, but I wasn't aware that you knew what SE's DB architecture was. Or how they query the database. Or how much bandwidth they have available. Or...well anything that would allow you to argue intelligently with a community rep.

Like I said, it would have been nice but ultimately its a fairly unnecessary luxury. If I had to choose between this and the laundry list of already planned additions, I'd pick all of those additions over this one.

[Molly_Millions]

Please read. Obviously DB queries aren't secret, but I wasn't aware that you knew what SE's DB architecture was. Or how they query the database. Or how much bandwidth they have available. Or...well anything that would allow you to argue intelligently with a community rep.

Like I said, it would have been nice but ultimately its a fairly unnecessary luxury. If I had to choose between this and the laundry list of already planned additions, I'd pick all of those additions over this one.

I do have experience working with databases that contain numbers of accounts about 10 orders of magnitude larger than the numbers on each world server. We can query that database joining about 20 to 30 tables and receive results in a matter of seconds. It's obvious from the reps response that the LS ui query uses a single table. Something doesn't sound right to me.

[Rivienne]

I do have experience working with databases that contain numbers of accounts about 10 orders of magnitude larger than the numbers on each world server. We can query that database joining about 20 to 30 tables and receive results in a matter of seconds. It's obvious from the reps response that the LS ui query uses a single table. Something doesn't sound right to me.

I agree with most of this (I have exp in large databases myself), but one thought occurs to me: what if they don't consistently store it in another accessible table either? It sounds like they are using a single table design for LS, and for FC.

I.E. they are storing the date in the FC table. Which means the only way to get this would be to join to the FC table, which not everyone has.

It could be literally as simple as, they can't do it reliably because the data is only stored in the FC table. So LS -> left join Players -> left join FC, it still might not show if the person isn't currently in a FC.

I know this should be easy, I agree. But it does sound like a potential schema change would be required and nobody wants to sign off on a schema change in a live environment. No matter how trivial. Not in my experience anyway.

[Molly_Millions]

I agree with most of this (I have exp in large databases myself), but one thought occurs to me: what if they don't consistently store it in another accessible table either? It sounds like they are using a single table design for LS, and for FC.

I.E. they are storing the date in the FC table. Which means the only way to get this would be to join to the FC table, which not everyone has.

It could be literally as simple as, they can't do it reliably because the data is only stored in the FC table. So LS -> left join Players -> left join FC, it still might not show if the person isn't currently in a FC.

I know this should be easy, I agree. But it does sound like a potential schema change would be required and nobody wants to sign off on a schema change in a live environment. No matter how trivial. Not in my experience anyway.

Or even add a new field for last login date to the table that character data is stored in.