You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Kevin Meyer <ke...@kmz.co.za> on 2011/02/01 07:27:37 UTC

Documentation: SQL object store

Hi Everyone,

I've started slowly chipping away at writing the supporting documentation
for the SQL object store (thanks Dan for suggesting 25 minute slots!).

Now my question is: If you have an opinion, what would you like to see
in such a document?

At the moment I'm just putting down whatever comes into my head, with
a view of later editting it into a coherent document, but obviously
there are questions of level of detail, etc. For example, should I
really bother with describing what persistance is, and how the domain
classes are introspected?!

Yes to: what SQL data types are used by default, yes to: how to override
the automappers and provide your own mapper, yes to: how collections
and parent/child relatonships are handled, etc.

What else?

Regards,
Kevin



Re: Documentation: SQL object store

Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
On 1 Feb 2011 at 6:57, Dan Haywood wrote:

> > Now my question is: If you have an opinion, what would you like to see
> > in such a document?
> >
> It'd be worth showing examples of all the different types of mappings 
> supported, as well as those that are not supported.
> 

Thanks for these and other comments. Every little bit helps.

Regards,
Kevin


Re: Documentation: SQL object store

Posted by Dan Haywood <dk...@gmail.com>.
On 01/02/2011 06:27, Kevin Meyer wrote:
> Hi Everyone,
>
>
> Now my question is: If you have an opinion, what would you like to see
> in such a document?
>
> At the moment I'm just putting down whatever comes into my head, with
> a view of later editting it into a coherent document, but obviously
> there are questions of level of detail, etc. For example, should I
> really bother with describing what persistance is, and how the domain
> classes are introspected?!
I don't think so, no.

That said, if you do find yourself writing "introductory" material like 
this, we can always move it.  The place for such stuff should probably 
be the "core" documentation (core/src/docbkx/guide/isis-core.xml), which 
is what I'm chipping away at myself.

> Yes to: what SQL data types are used by default, yes to: how to override
> the automappers and provide your own mapper, yes to: how collections
> and parent/child relatonships are handled, etc.
It'd be worth showing examples of all the different types of mappings 
supported, as well as those that are not supported.

For example:
- Id generation - how is that supported?
- optimistic locking - how supported?
- one<->many
- one<-many
- one->many
- two one<->many relationships between same types A and B (if I recall, 
this isn't supported?)
- many<->many
- many->many
- subtype relationships (roll-up, roll-down, table per subtype)
- polymorphic relationships to interfaces


You could also peruse some of the Hibernate ORM docs for examples of 
mappings there; that might prompt you to consider some additional scenarios.



> What else?
Obviously, any additional entries required in isis.properties to enable 
the SQL object store.

In addition, as background it'd be worth explaining about the different 
subcomponents used by the object store: the OidGenerator, 
PersistAlgorithm, TransactionManager

Also, I know that the JPA object store has to configure a different 
ClassSubstitutor/ObjectFactory, because it leaves the ORM to perform 
cglib proxying.  I don't think you have any similar restrictions, but it 
might be worth saying so.

> Regards,
> Kevin
>
>

Pomodoro Technique

Posted by Dan Haywood <dk...@gmail.com>.
On 01/02/2011 06:27, Kevin Meyer wrote:
> I've started slowly chipping away at writing the supporting documentation
> for the SQL object store (thanks Dan for suggesting 25 minute slots!).

What Kevin is referring to here is something I mentioned to him on IRC, 
namely the "Pomodoro Technique" [1].  The idea is to work solely on a 
single task for 25 minutes; if something else pops into your mind while 
working on that task, then make a quick note of it but then carry on 
with what you are meant to be working on.

For myself, I've been using this technique to just do a little on Isis 
each and every day.  I try to do either one or two "pomodoros" on Isis 
before starting getting down to (proper, paid, non-Isis) work, and I try 
to do one or two pomodoros at the end of the working day if I have the 
energy.

I'm keen that we maintain momentum with Isis, but obviously we all have 
"real" jobs to do.  If you'd like to be contributing more to Isis but 
haven't managed to get started, why not try this technique and see if it 
works for you?

Cheers
Dan

PS: as an extension on this technique, keep a calendar and put a X in it 
for every day that you were able to perform a pomodoro.  After a while, 
you won't want to break your streak.  Apparently Jerry Seinfeld (the US 
comedian) uses this to write new material every day.  Some of the 
authors at pragprog.com are also using it as a way of writing their books.

PPS: of course, this technique can be used for anything you want to work 
on, not just Isis !

[1] http://www.pomodorotechnique.com/