Re: [dali-dev] Test plugins

[Trân Lê <TRAN.LE@xxxxxxxxxx>]

Hi Dirk,
This is to recap this morning discussion concerning the DDL generation integration.

The dali.db plugin was design based on the pattern "Façade". It defines a high level API to the RDB by converting the interface of multiple RDB objects.

We made the dali.db plugin completely independent from the Dali object model, and tightly couple with the RDB object model. (Note that dali.db and dali.core share the dali.utility plugin. This was a choice made to avoid duplicate code. The dali.db plugin should really use it own set of utilities).


We came up to three possible options for the integration of the DDL generation functionality:

1. Create a new plugin that will depend on dali.core and RDB

2. Incorporate dali.db into dali.core

3. Add the necessary API to dali.db plugin to provide all necessary functionality for the DDL generation perform it task. The DDL generation might need to access dali.db functionality through dali.core.

Hope this helps.
-Tran

---

From Dirk le Roux <dirk.leroux@xxxxxxxxx>

Sent Thu 1/26/2006 6:34 AM

To General Dali EJB ORM developer discussion. <dali-dev@xxxxxxxxxxx>

Subject Re: [dali-dev] Test plugins

---

Hi All,

So where does DDL generation fit in? Somewhere there will have to be a
class that contains dali.core model objects and RDB model objects (One
class that imports both). Currently none of our projects support this.
dali.core can not reach RDB and dali.db can not reach dali.core. 
My logic(and gut feel) would suggest that dali.db depend on dali.core
and not the other way round. dali.db can then use dali.core and rdb
code and dali.core remains a pure mapping model. The code to look up
possible cols can then be moved out of the model and into the
controller class.

Let me know what you think.

Dirk le Roux

On 1/25/06, Paul Fullbright <paul.fullbright@xxxxxxxxxx> wrote:

According to our rather lengthy discussion today, it seems we have
settled on the following:


1) The component 'Dali' will have no subcomponents and, as such, will
retain its existing plugin structure.
    org.eclipse.dali.utility
    org.eclipse.dali.db (dependency on *.utility)
    org.eclipse.dali.core (dependency on *.utiltity and *.db)
    org.eclipse.dali.edit (dependency on *.core)
    org.eclipse.dali.ui (dependency on all above)

We debating pulling *.db and/or *.utility code into the *.core plugin
and pulling the *.edit code into either the *.core or *.ui plugins, but
decided against for the following reasons:
       - *.db should be separate from *.core in order to shield .*core
from any rdb/dtp code.
       - *.utility should be separate from *.core to prevent circular
references between *.core and *.db.
       - *.ui should be separate on general principles
       - We don't clearly know where *.edit would better be placed.

We also debated renaming *.utility and *.db to *.core.utility and
*.core.db but decided against as it was needless, there being no concept
of dali subcomponents.


2) Test plugins shall follow the observed convention of naming and not
the stated convention.
    org.eclipse.dali.utility.tests
    org.eclipse.dali.db.tests
    org.eclipse.dali.core.tests
    org.eclipse.dali.ui.tests

We debating using the stated convention of naming
(org.eclipse.dali.tests.*) but decided against due to the lack of
observed obedience and because it better describes what each test plugin
is testing.

We also debated rolling the utility and db tests into the core test
plugin, but decided against since db tests may require further
dependencies that we don't want to require of core test developers and
to maintain test->plugin clarity.


Committers:  PLEASE RESPOND if you have any objections.

Thanks,
- Paul
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev

---

_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev