We changed our privacy policy. Read more.

Hot answers tagged

26

so that at some point in the future I can swap out my ORM implementation. I severely doubt that will ever happen over the life of the product, so I'm essentially putting effort into something that I'll probably never reap the benefits of In my experience, the typical enterprise project never swaps out: Database ORM Language I don't know the numbers, ...


9

Taken from https://stackoverflow.com/questions/14028198/jpa-why-the-annotations-are-applied-on-getter-or-field, if you apply the annotation to the field, the jpa provider directly sets the field. If you annotate the getter, the JPA provider uses the accessor methods. See Chapter 2.3.1 of the specification here. I prefer field access for a couple of reasons:...


7

One option is to use an in-memory testing database such as H2; it tends to be about about 10x faster than a standard disk-using database, and with lower startup/teardown times. Whether it will help does largely depend on whether the JPA issues you are having are general enough that they will still fail on different database. Not much point running tests ...


6

In the long run, going database model first will very often pay off compared to what appears to be a quick win of going client model first. Before I explain, let me just disclaim that your domain model is something entirely different and it should be defined even before worrying about the database layer. Also, there are trivial cases where client model ...


5

is it worth it? That would entirely depend on the application. If you're writing an internal application for a single company, forget it. That database will outlive the application by years, possibly decades. Unless of course you've been given to understand from the outset that the database is planned to be replaced by something else in the near future. If ...


4

Both Hibernate and EclipseLink use the Proxy design pattern to implement lazy/eager loading of entity relationships. Proxies are weaved into Java bytecode at build time (statically) or at runtime (dynamically) - basically enhancing your Entity POJOs. Other features, such as dirty checking are also weaved into bytecode. This is an application of Aspect ...


4

From my experience: no, it is not worth it in case of JPA/Hibernate. Is "programming to the interface" worth it when it comes to stuff like JPA? It is, but has nothing to do with JPA specifically. You can do "programming to the interfaces" of the Hibernate. This is not about hiding a framework under a standard, it is about SOLID. Have you ever ...


3

If we start developing using a self-hosted PostgreSQL server and later want to change to Amazon RDS PostgreSQL or SQL Server, will we run into lots of problems? Not really. We recently migrated from Oracle 11g to Azure SQLServer and it just took us to change some Spring properties. spring.datasource.url=jdbc:sqlserver://<host>:<port>;...


3

At the risk of sounding contrarian here, I would say, that yes, it is worth it. And it is not. The issue is not so much in switching your ORM or database provider as such. It is more of an issue of separation of concerns and staying agile. Once you start relying on some implementation detail of a library, you start creating deeper and deeper entanglements ...


3

Other people have answered with "Mock out your DB!" - but what's the point in mocking out your DB layer if you actually need to test how it interacts with your code? What you're looking for is integration tests and/or automated UI tests. You mentioned that the problem happens when: *If you click the save button twice* The only way to test for this is to ...


3

Databases can be very easy to unit test - you need stored procedures and transactions. This what Microsoft says about Database unit testing. You can also run unit tests against a database, writing your tests in Java or C# by setting up a DB connection, beginning a transaction, write whatever data you want to use for the test to the DB, run the tests and ...


2

I had a simple case with I first solved with an enum that was stored inside a ElementCollection. It would suffice in your situation because you would most likely just query the whole collection and then you can do your operations on the Set. If you want on the other hand to have your choices to be more extensible you should create another Entity for ...


2

My approach is: prefare unidirectional relations (eg. when loading role, you don't usually need everyone with that role, and if you need it for user management, you can quary for it) prefare lazy loading, so you don't manipulate huge graphs by accident if you don't need entity as result of query, return non entity object (via select new). JPA is not ...


2

Optimistic locking using version numbers is based on the principle that you know which version of the data was retrieved from the database before making any modifications, so that you can verify that no intermediate updates have taken place between your retrieval of an entity and writing your changes back. For this to work, the version number must be an ...


2

As you see, the solution might not be very satisfying. The problem of data access at all is, that we have to consider many different aspects which make code not 100% reusable. It's about transactions and locking, and the way e.g. ORM maps a relational database to objects and vice versa. Mostly if you try to write architecture components, trying to solve the ...


2

You are correct - that will occur. But i think that you dont need optimistic locking for the posts. AFAICT, social networks allow the user generated content to be altered only be the owner/poster themselves. Writing conflicts should therefore not be a real issue. You can disable locking for those entities. In order to get the counter correct, re-count with ...


2

There's a limt on how long column names can be in mosd DBMSes: Postgres and MySQL allow 64 characters, Oracle only 30. It's fine when you have a long name for something primary, but once you start considering related tables, you might need to combine FK column names to show their relationship. For instance, if you have an worldwide_catalog_id column on an ...


2

You need to find a balance. AnIncrediblyLongVariableOrTableName is almost as hard to deal with as TooShrt - especially when you're looking at a block of code (or a sproc) that mentions a half dozen of them within 20 lines. If the names are too long, you'll see a significant performance hit - in your developer's brains. It will be harder to read the code,...


2

From@URL Java Doc: Validates the annotated string is an URL. The parameters protocol, host and port are matched against the corresponding parts of the URL. and an additional regular expression can be specified using regexp and flags to further restrict the matching criteria. Note: Per default the constraint validator for this constraint uses the java.net....


2

Even when creating a fresh application and deciding to use an ORM, it can be very tricky, especially if you're not familiar with how the ORM works. An ORM can make it seem easier to deal with the database, but that's really only true with a simple schema. When things get more complex, you not only have to understand the database but also the ORM layer. In ...


2

Sounds like a nightmare. In theory, if you publish the events to a message queue you can have them processed against the master database and have undo event work fine. However, with multiple clients all processing transactions I'm not sure I would trust it not to go out of sync. Really each client should potentially be getting a lock on all databases before ...


2

Short Answer Don't use JPA locking to implement this. It's insufficient to deliver a good experience in the style you defined. Record check-out information about the widgets instead. Why? Some aspects of your desired user experience ("idea/flow") do not fit well with JPA or database locking methods. "While a widget is locked it will not ...


1

For quite simple apps, returning such entities works just fine and gets you started really quick. You are likely to need those for the database interactions anyway and the returned entities are usually 1:1 mapping to database. For more robust applications which you want to scale better, completely circumventing those entities on reads by using plain SQL ...


1

To ease the tedium of creating the map I'll often write a little utility:. (skeleton code) Map addKeyValuePairs(Map m, Object...pairs) { // TODO test that pairs has an even number for (int i=0; i<pairs.length; i+=2) { // TODO Add null checks as desired m.put(pairs[i].toString(), pairs[I+1].toString()); } return m; }


1

It's over engineering or just paranoia ;p ? I don't think it's either. Yes, a map is a generic data structure but it's also the first thing you reach out for when you need key-value or param-value pairs. So most people do it like that and then the rest of the code is just them being responsible and not do things like this: Map<String, Object> ...


1

I did solve this issue so this approach is not neccesary. Here is how I did it: Using transformers. So the field area is defined like this: @Transformation(fetch = FetchType.EAGER, optional = false) @ReadTransformer(transformerClass = AreaAttributeTransformer.class) @WriteTransformers({ @WriteTransformer( transformerClass = ...


1

I think your confusion stems from the Product table's general lack of utility, since it contains an ID and nothing else. However it's not a big deal. When defining JPA entities, I would start with the Products table and define each of the child objects as separate classes. Then include those in the Product class: @Entity @Table(name = "PRODUCT") public ...


1

Sometime ago, i asked on SO a question that include if i have to implements my service as they're using JPA managed entities ? Here are the two points of my own answer that should interest you : I don't have to abstract the fact that i use managed entities, this will lead to complex and unefficient code I choosed JPA, i won't switch for it which is ...


1

The question is already a bit aged, but maybe someone still stumbles upon it. Most of the mvc-based PHP frameworks offer a feature called scaffolding. With this feature you can easily create simple masks for CRUD operations. Instead of ids ususally a display-field is used for defining relations. I often use CakePHP to achieve what you describe, but it ...


1

I prefer the Table Data Gateway pattern, i.e. a stateless object for roughly each entity type, containg methods such as void CustomerRepository.createCustomer(Customer c) List<Customer> CustomerRepository.getCustomersByCountry(String country) Easy to add additional handling such as serialization, error handling, logging, validation, caching. Easy ...


Only top voted, non community-wiki answers of a minimum length are eligible