Re: Query Builder internals

Hi,

On 2/24/06, Piotras <[email protected]> wrote:
> > OK. Perhaps we could add a UNIQUE constraint in the table definitions
> > to enforce this. Otherwise we can easily end up with strange errors.
>
> Can we return DUPLICATE ERR easily then?

Yes, once we have proper database error reporting...

> Not at all. This is very difficult to make two features as one.
> These features are: translation and translated content being translated
> by particular translator. We are far the from second feature so you can not
> create content with lang X if you do not have content with lang 0.
>
> Basically you always have some lang 0 , it may be English , Russian, etc.
> Then you can start translate content and create lang X "entry".

Ah, now I see it! Thanks.

> > OK. Having the "sitegroup" column in all tables is quite nice for some
> > operations even though it isn't required and can even cause
> > inconsistencies due to the non-normalized table structure it creates.
> > I'd suggest always having the column and mandating that the MultiLang
> > sitegroup always be the same as the main object sitegroup, even at the
> > expense of potential problems.
>
> OK, but ML content is not accessible by any API or internal function as standalone
> record.

The sitegroup column is good for things like indexing and table
clustering that do not need to be reflected in the API.

> In practice you have few languages available on website so replicating all lang
> content shouldn't be so difficult.

OK, I can do that.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - [email protected]
Software craftsmanship, JCR consulting, and Java development