by Bozho | May 14, 2011 | Aggregated, Software
JPA and domain-driven design don’t mix well. In fact, JPA “entities” are representatives of the anemic data model that Fowler warns against. I have already discussed DDD in the light of JPA and dependency injection, so I won’t go into much details here whether anemic data model is bad or not (for the record: I don’t think it’s bad). But for the times you need to inject dependencies into entities standards don’t give you a hand. The only option is @Configurable, which requires aspectj weaving, which is “black magic” to me. So why you can’t inject dependencies into entities? Because they are created by you and not by a dependency injection framework. Well, here’s a weird idea. What if JPA 3 had EntityManager.createEntity(Foo.class) so that your entities are managed all the time? Then you’ll be able to inject dependencies different than other entities (which is already handled by JPA through associations). How will it work? JPA will require a DependencyManager which will provide the dependencies, handle their lifecycle, etc. CDI will be the default dependency manager of course, but any framework (spring, guice, etc) can plug-in their implementation whenever you em.create(..) your entity it will have its dependencies set – as if the entity is created by your DI framework this would mean that the “transient” state of entities will not exist (if you choose the create() method, that is) But… detached entities, or the cases when you need to create the entities where you should not have access to the entity manager (in a controller for example) are the most important thing. And I can’t give a satisfactory...
by Bozho | Apr 30, 2011 | Aggregated, Software
The usual choice for a collation in MySQL is utf8_general_ci (or whataver_ci). ci means “case insensitive” (there are also the _cs collations). All is fine with that, but if you are storing and then comparing Base64-encoded data, you may have a hidden issue. Base64 encoded data is case-sensitive, but the comparison with _ci collations is case-insensitive. So you are storing some base64 and then try to query for it: user1 base64: A543rFgTregW user2 base64: A543rFGtregw When you SELECT * FROM table WHERE base64column="..." you can get the incorrect user. I agree this is rare (as you should rarely query for binary data, no matter the representation), but it can waste a lot of time researching when it happens (it hasn’t happened to me, luckily). The solution is to use VARBINARY. The usual choice for a collation in MySQL is utf8_general_ci (or whataver_ci). ci means “case insensitive” (there are also the _cs collations). All is fine with that, but if you are storing and then comparing Base64-encoded data, you may have a hidden issue. Base64 encoded data is case-sensitive, but the comparison with _ci collations is case-insensitive. So you are storing some base64 and then try to query for it: user1 base64: A543rFgTregW user2 base64: A543rFGtregw When you SELECT * FROM table WHERE base64column="..." you can get the incorrect user. I agree this is rare (as you should rarely query for binary data, no matter the representation), but it can waste a lot of time researching when it happens (it hasn’t happened to me, luckily). The solution is to use...
Recent Comments