Tim Holloway

I think the numeric type internal data format is always double, even for integer cell values (int is equivalent to floating-point with an exponent value of 0).  You'd have to get the cell's data format to know the precise display formatting for the value.

You should be able to retrieve the cell metadata. That will tell you the data type and the Excel formatting options defined for that cell.

I was afraid you were going to say that.

SQL is not well-designed for this kind of thing. It can work on horizontal slices and on vertical slices, but it has no simple syntax for inter-row operations such as this.

Your simplest approach would either be a stored procedure or an independent application (for example, in Java code).

The thing that doesn't make sense here is precisely because your table doesn't appear to have initial_date and final_date columns. Instead you're using the same column value (t.time) for both dates.

For myself, I'd just SELECT date_part('day", final_date - initial_date) AS day_diff WHERE day_diff > $too_long as a rough computation, and if you're worried about hour/minute/seconds differences resulting in a day to short, add an interval of 23h 59m 59.99s or so to the date difference calculation. And not need all that fancy stuff.

PostgreSQL has a wealth of date/time functions, so there are lots of options to play with.

Some company cafeterias are open to the general public. Some are not. One company had their own Taco Bell inside a secured area, but I think that since it was an old-style corporation that they were subsidizing lunches. Although my first IT job had an open cafeteria and we had voucher cards.

It's odd that you'd be worrying about parking for lunch if you work downtown, though, Randy. Even in my benighted little burg there have always been many good places to eat within a few short walking blocks of work downtown. It was the suburban campuses that were the nightmare - no sidewalks and sprawl made driving to lunch almost mandatory.

I don't understand it either. Partly because it's incomplete and we can only see how you're trying to do it and not what you actually what you want to really do. Partly because I'm confused about the need for all those transformations on dates and whether they are even necessary.

One thing to keep in mind, though. Timestamp-style "date" fields in  most databases are imprecise. Unless it's a true date (with no time) field or you have an integral number of seconds, treat the date/time values with the same care you would treat floating-point numbers.

This fuzziness is also why date/time columns are usually not safe to use as primary keys.

Vaibhav Gargs wrote:Thanks Tim. Suppose the client is having cookie as ABC which on HTTPS after encryption becomes XYZ. Now, the attacker intercepts the request in between and use the encrypted cookie say XYZ to request the server. Will it work? I am sorry - new in security so don't have much idea about all this stuff.

The problem there is that the attacker is intercepting an encrypted data stream. Without the secret knowledge that the true client has, an intermediary (man-in-the-middle) cannot decrypt it to get the cookie ID. Or, for that matter, any other sensitive information that may have been sent back in that response stream.

Vaibhav Gargs wrote:

Stephan van Hulst wrote:As soon as an attacker knows the session cookie, you've lost.

Using HTTPS only helps in preventing an attacker to get the cookie in the first place.

Thank you Stephan. How does HTTPS prevents to get the cookie? The cookie will be transmitted along with the request, can't the attacker sniff the request and steal the cookie?

No, because the cookie is inside the encrypted data. They'd have to be able to decrypt the HTTPS before they could get the cookie ID.

The cookie is generated by the server, so the server sends it to the client first. The client then sends it back to the server to anchor the user session on the next request, the user sends it back again as part of the response and the cookie thus shuttles back and forth. And, as I said, the client should never cache the cookie for private use, since the server has the right to change the jsessionid value without notice. The only valid cache use of the cookie on the client is to send the next request and the next server response may change that cookie's value.

IntelliJ added a desktop GUI designer (for Swing) a number of years ago that I really liked. I write very few desktop GUI apps these days, but it was nice to see it - before that, you had to go all the way back to Borland's Visual Café at the Turn of the Millenium to find a good GUI designer for Java. And hardly anyone remembers Visual Café anymore.

One really great thing about IntelliJ GUI design was that the code it generated was self-sufficient. Visual Café generated code that was highly dependent on proprietary helper classes, and as an author of open-source software that was not tolerable. In fact, I wrote a Perl script that took the Café-generated code and removed the proprietary stuff.

Glen Lang wrote:Food for thoughts, thanks. I do agree with you, unfortunately, I wasn't given a choice... You know how things go...

4. It's less expensive. Because anyone familiar with Maven knows where to look for things in the project, you don't have to spend time (== $) teaching new hires and temps your quirky project standards. And they don't have to spend time (== $) remembering where to put/dig for stuff when you need them to work on projects.

OK. Sorry. I mis-read some stuff.

The stuff you are describing is a way to define Spring configuration in logic, rather than via direct annotations or a config file. The @Bean methods are factory helpers. And while you have defined 2 different methods which construct  ClientServiceImpl objects, these are distinct objects, even though they both belong to the same class. The Spring factory retrieves beans by name. So these are "singleton" in the sense that there should only be one instance of clientService1 (that is, a ClientServiceImpl named "clientService1") and one instance of clientService2, they are not literally Singletons, in that the same class is instantiated twice. And, again, only if you're going by default rules. If you wanted to you could, for example, define a single instance of clientService1, but have Spring generate multiple instances of clientService2, just by setting the Spring configuration options accordingly.

The @Bean thing confused me, since I've never had need of a logic-based configuration and I was thinking it was a CDI re-refinition of one of the more common Spring annotations.

In fact, for DAO's, I use the @Repository annotation directly on the DAO class definition. Along witjh @Transactional.

No, the ClientService is not a Spring bean the way you did it. And actually, the recommended way to create it would be to define the ClientService as a Spring bean and have Spring inject/Autowire the ClientServiceImpl into the ClientService class to be returned by the clientService1 method.

Or actually, since you've basically just created a mini-factory, ClientService should more properly be defined as a Java Interface that ClientServiceImpl implements and you'd configure Spring to manufacture and return a ClientServiceImpl to whatever downstream beans requested a ClientService.

The actual instantiation of ClientServiceImpl in either case would either be by annotating the ClientServiceImpl.java file as a Spring bean, or if this is not possible or desirable, to define it in your Spring configuration (applicationContext.xml or whatever).

After due reflection, I think that actually setting up an archetype with non-standard directory layout isn't really a good idea.

I'll admit that one of the first things that kept me from adopting Maven initially was its insistence on its own special directory structure. The second thing being that unlike Ant, you couldn't see what the rules being executed were.

But I've since learned to accept it. For a couple of reasons.

1. It's consistent. Every (standard) Maven project in the world has the same directory structure. That means that if I pass a project to someone in Outer Mongolia, they will instantly know where to find stuff without wasting time searching.

2. It's simple. The very thing that put me off about Maven - the fact that it does things by "magic" instead of explicitly-written rules means that you don't waste time setting up build rules (or in this case, POM overrides). The fact that the magic tools don't have to be told where the source, resources and other build inputs are located is a further benefit.

3. It's authoritative. Several new build systems have been developed since Maven that act on the same general philosophy. I'd expect them to also follow the same general organization, thus reducing their learning curves and helping support their own adherence to the first 2 items listed above.

I'm NOT saying to turn the shop upside down and re-code all the builds willy-nilly. But it would be a good idea to migrate to standard directory structure as new builds are created (which is what archetypes are for). It's not so burdensome to have 2 sets of rules rather than 1 while in transition, and if you already had a consistent structure, it shouldn't even be that hard to put together a migration script to be used as projects come up for maintenance.

Campbell Ritchie wrote:

Ryan McGuire wrote:. . . there's an XKCD for that. . . .

And that XKCD is very appropriate for the puzzle in the first post.

Or, as someone once said long ago - and has often been repeated, "Nobody likes a smartass."

And as someone else once said, "There's an XKCD for everything."