Tuesday, March 4, 2014

Markdown editor for blogger

Markdown is quite popular these days and I like it for it’s simplicity. So I’ve been searching for a way to integrate it in my blog writing workflow. In Blogger, it’s unfortunately not an option.

There I could go:

  • either for WYSIWYG editor or
  • manual HTML writing.

However WYSIWYG generates too much HTML I don’t need. Moreover some pre-publish manual HTML editing is a pain then. And the other option I consider it rather slow/unproductive.

So, I looked for other options, and found stackedit.io. Even this post is (and couple others as well) written in it.

stackedit

I consider Stackedit great as it:

  • is Markdown editor,
  • is open source (see github repo),
  • has awesome UI (including live preview, key bindings, …),
  • has integration with other popular services that I use anyway:
  • has active community (just check the stars count and commit activity on the github repo) and
  • has impressive feedback time (resolution on my issues/questions came in couple hours)

So my post writing/editing workflow goes like this:

  1. write/edit post on stackedit.io,
  2. sync it to google drive and
  3. publish/republish it to blogger.

That’s it! No further in-blogger updates required!

Blogger specifics

Still there are some specifics in my workflow (to provide smooth blogger integration).

  • using the Interpreted variables: title and tags via:
---
title: Markdown editor for blogger
tags: blogger markdown stackedit.io
---

p6spy 2.0.0 is out!

After 8 years P6spy came to it’s next stable release!
You can get it here.

The last stable release happened (based on maven central repo) on 27-Dec-2005 (1.3 version). That is quite some time, so one would expect many things to happen in the meantime. Well the truth is that project was (half) dead for quite some time.

Changes

I can’t comment on full history since 1.3 release (since my interest in project started last summer), still I’ve noticed following:

  • project hosting was moved from sourceforge to github,
  • major part of the legacy code was refactored,
  • Java 6/7 JDBC API support introduced,
  • proxying via modified JDBC URLs only was implemented,
    So for for MySQL original url would be:

    jdbc:mysql://<hostname>:<port>/<database>

    the one proxied via p6spy would one:

    jdbc:p6spy:mysql://<hostname>:<port>/<database>

    without a need for any further configuration,

  • XA Datasource support has been introduced,
  • configuration via:
    • system/environment properties and
    • JMX properties
    • as an alternative to file configuration only
    • or even zero config use case supported,
  • slf4j support (more flexible as previously used log4j),
  • junit tests were migrated to junit 4 (well most of the old ones were failing anyway),
  • Continuous integration using Travis was setup providing testing on popular:
    • DB systems (namely: Oracle, DB2, PostgreSQL, MySQL, H2, HSQLDB, SQLite, Firebird, and Derby), see build status on: travis-ci as well as
    • application servers (namely: Wildfly 8, JBoss 4.2, 5.1, 6.1, 7.1, Glassfish 3.1, 4.0, Jetty 7.6, 8.1, 9.1, Tomcat 6, 7, 8, Resin 4, Jonas 5.3 and Geronimo 2.1, 2.2), see build status on: travis-ci.

Full changelog

For the full changelog, see issues fixed in: 2.0.0-alpha1 as well as 2.0.0.

Postgres and Oracle compatibility with Hibernate

There are situations your JEE application needs to support Postgres and Oracle as a Database.
Hibernate should do the job here, however there are some specifics worth mentioning.
While enabling Postgres for application already running Oracle I came across following tricky parts:

  • BLOBs support,
  • CLOBs support,
  • Oracle not knowing Boolean type (using Integer) instead and
  • DUAL table.

These were the tricks I had to apply to make the @Entity classes running on both of these.

Please note I’ve used Postgres 9.3 with Hibernate 4.2.1.SP1.

BLOBs support

The problem with Postgres is that it offers 2 types of BLOB storage:

  • bytea - data stored in table
  • oid - table holds just identifier to data stored elsewhere

I guess in the most of the situations you can live with the bytea as well as I did. The other one as far as I’ve read is to be used for some huge data (in gigabytes) as it supports streams for IO operations.

Well, it sounds nice there is such a support, however using Hibernate in this case can make things quite problematic (due to need to use the specific annotations), especially if you try to achieve compatibility with Oracle.

To see the trouble here, see StackOverflow: proper hibernate annotation for byte[]

All- the combinations are described there:

annotation                   postgres     oracle      works on
-------------------------------------------------------------
byte[] + @Lob                oid          blob        oracle
byte[]                       bytea        raw(255)    postgresql
byte[] + @Type(PBA)          oid          blob        oracle
byte[] + @Type(BT)           bytea        blob        postgresql

where @Type(PBA) stands for: @Type(type="org.hibernate.type.PrimitiveByteArrayBlobType") and @Type(BT) stands for: @Type(type="org.hibernate.type.BinaryType").

These result in all sorts of Postgres errors, like:

ERROR: column “foo” is of type oid but expression is of type bytea

or

ERROR: column “foo” is of type bytea but expression is of type oid

Well, there seems to be a solution, still it includes patching of Hibernate library (something I see as the last option when playing with 3.rd party library).

There is also a reference to official blog post from the Hibernate guys on the topic: PostgreSQL and BLOBs. Still solution described in blog post seems not working for me and based on the comments, seems to be invalid for more people.

BLOBs solved

OK, so now the optimistic part.

After quite some debugging I ended up with the Entity definition like this :

@Lob
private byte[] foo;

Oracle has no trouble with that, moreover I had to customize the Postgres dialect in a way:

public class PostgreSQLDialectCustom extends PostgreSQL82Dialect {

    @Override
    public SqlTypeDescriptor remapSqlTypeDescriptor(SqlTypeDescriptor sqlTypeDescriptor) {
    if (sqlTypeDescriptor.getSqlType() == java.sql.Types.BLOB) {
      return BinaryTypeDescriptor.INSTANCE;
    }
    return super.remapSqlTypeDescriptor(sqlTypeDescriptor);
  }
}

That’s it! Quite simple right? That works for persisting to bytea typed columns in Postgres (as that fits my usecase).

CLOBs support

The errors in misconfiguration looked something like this:

org.postgresql.util.PSQLException: Bad value for type long : ...

So first I’ve found (on String LOBs on PostgreSQL with Hibernate 3.6) following solution:

@Lob
@Type(type = "org.hibernate.type.TextType")
private String foo;

Well, that works, but for Postgres only.

Then there was a suggestion (on StackOverflow: Postgres UTF-8 clobs with JDBC) from to go for:

@Lob
@Type(type="org.hibernate.type.StringClobType")
private String foo;

That pointed me the right direction (the funny part was that it was just a comment to some answers). It was quite close, but didn’t work for me in all cases, still resulted in errors in my tests.

CLOBs solved

The important was @deprecation javadocs in the org.hibernate.type.StringClobType that brought me to working one:

@Lob
@Type(type="org.hibernate.type.MaterializedClobType")
private String foo;

That works for both Postgres and Oracle, without any further hacking (on Hibernate side) needed.

Boolean type

Oracle knows no Boolean type and the trouble is that Postgres does. As there was also some plain SQL present, I ended up In Postgres with error:

ERROR: column “foo” is of type boolean but expression is of type integer

I decided to enable cast from Integer to Boolean in Postgres rather than fixing all the plain SQL places (in a way found in Forum: Automatically Casting From Integer to Boolean):

update pg_cast set castcontext = 'i' where oid in ( select c.oid from pg_cast c inner join pg_type src on src.oid = c.castsource inner join pg_type tgt on tgt.oid = c.casttarget where src.typname like 'int%' and tgt.typname like 'bool%');

Please note you should run the SQL update by user with provileges to update catalogs (probably not your postgres user used for DB connection from your application), as I’ve learned on Stackoverflow: Postgres - permission denied on updating pg_catalog.pg_cast.

DUAL table

There is one more specific in the Oracle I came across. If you have plain SQL, in Oracle there is DUAL table provied (see more info on Wikipedia on that) that might harm you in Postgres.

Still the solution is simple. In Postgres create a view that would fill the similar purpose. It can be created like this:

create or replace view dual as select 1;

Conclusion

Well that should be it. Enjoy your cross DB compatible JEE apps.