Tine 1:n:m:... records?

Nathan_Gray-2 2008-02-05 17:28:08 UTC #1

Much of pERP’s data is in 1:n:m relationships.
For example, 1 Order has {1,n} OrderLines, OrderLines have {0,m}
OrderLineDetails.
I’m wondering how the Tine Record_Interface would support such things,
and what the keys would look like?
Would each of Order, OrderLines, OrderLineDetails need to have an auto-
incrementing ID, or could multi-part keys like
{order_id, order_line_id, order_line_detail_id}
{1,0,0}, {1,1,0}, {1,1,1}, {1,1,2}, {1,2,0}, etc be used?

Nathan Gray
nathan at goarctic dot com

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Lars_Kneschke-2 2008-02-05 18:17:11 UTC #2

“Nathan Gray” nathan@goarctic.com schrieb:

Much of pERP’s data is in 1:n:m relationships.
For example, 1 Order has {1,n} OrderLines, OrderLines have {0,m}
OrderLineDetails.
I’m wondering how the Tine Record_Interface would support such things,
and what the keys would look like?
Would each of Order, OrderLines, OrderLineDetails need to have an auto-
incrementing ID, or could multi-part keys like
{order_id, order_line_id, order_line_detail_id}
{1,0,0}, {1,1,0}, {1,1,1}, {1,1,2}, {1,2,0}, etc be used?

Hello Nathan!

The idea is to have a record. The record can have the following properties
for example:

description: datatype string
orderId: datatype integer
orderLines: datatype recordSet (containing multiple records)

The orderLines would be of the type Egwbase_Record. The recordSet contains
multiple objects of the same datatype(class instance of Egwbase_Record).
Inside the recordSet any record gets identified by its unique key.
Any items would have it’s own id, as the data are separated by different
classes.

If I understood your question correctly, I don’t think that we need
multi-part keys.

–
Lars Kneschke
CTO OfficeSpot.Net
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg

eGroupWare Support: http://www.egroupware-support.net
OfficeSpot.Net Collaboration Server: http://cs.officespot.net
our proposal for the next major eGroupWare release: http://www.tine20.org

E-Mail: mailto:l.kneschke@metaways.de
Web: http://www.metaways.de
Tel: +49 (0)40 317031-21
Fax: +49 (0)40 317031-921
Mobile: +49 (0)175 9304324

Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Geschäftsführung: Hermann Thaele, Lüder-H.Thaele

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Nathan_Gray-2 2008-02-05 19:06:22 UTC #3

The idea is to have a record. The record can have the following
properties
for example:

description: datatype string
orderId: datatype integer
orderLines: datatype recordSet (containing multiple records)

The orderLines would be of the type Egwbase_Record. The recordSet
contains
multiple objects of the same datatype(class instance of
Egwbase_Record).
Inside the recordSet any record gets identified by its unique key.
Any items would have it’s own id, as the data are separated by
different
classes.

Ok, that makes sense. Order and OrderLine would extend
Egwbase_Record_Abstract or something, and have
Egwbase_Record_RecordSet objects.

If I understood your question correctly, I don’t think that we need
multi-part keys.

Need? No. Can use at all? No.

Another question has come to mind as we poke at your demo.
I have more than 20 applications in my eGroupWare. We fear that
little accordion on the side won’t fit the applications + anything
that comes down from them. At 24px each, that takes up quite a bit of
space.
For example, pERP’s Accounts Receivable has the sub-sections Clients,
Client Branches, Shipments, Invoices and Receipts, and pERP has about
8 applications to it.
What’s the plan for the overflow?

Nathan Gray
nathan at goarctic dot com

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Cornelius_Weiss 2008-02-05 19:14:27 UTC #4

Hi Nathan,

Another question has come to mind as we poke at your demo.
I have more than 20 applications in my eGroupWare. We fear that
little accordion on the side won’t fit the applications + anything
that comes down from them. At 24px each, that takes up quite a bit of
space.
For example, pERP’s Accounts Receivable has the sub-sections Clients,
Client Branches, Shipments, Invoices and Receipts, and pERP has about
8 applications to it.
What’s the plan for the overflow?

i also thought about this some days ago. My idea is to group apps in
the accordion, and only have the groups in it.

e.G.
Organiser, would contain: Addressbook, Tasks, Notes, Calendar
Crm: different crm apps, like: Leads, Calls, …
Erp: your apps

Would this fit for you?

cu
conny

Nathan Gray
nathan at goarctic dot com

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Cornelius Weiss
Metaways Infosystems GmbH
Pickhuben 2 - 4
20457 Hamburg
Germany

E-Mail: c.weiss@metaways.de
Web: http://www.metaways.de
http://www.tine20.org
Jabber: nelius@jabber.tine20.org

Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Geschäftsführung: Hermann Thaele, Lüder-H.Thael

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Nathan_Gray-2 2008-02-05 19:56:57 UTC #5

Hi Nathan,

Another question has come to mind as we poke at your demo.
I have more than 20 applications in my eGroupWare. We fear that
little accordion on the side won’t fit the applications + anything
that comes down from them. At 24px each, that takes up quite a bit
of
space.
For example, pERP’s Accounts Receivable has the sub-sections Clients,
Client Branches, Shipments, Invoices and Receipts, and pERP has about
8 applications to it.
What’s the plan for the overflow?

i also thought about this some days ago. My idea is to group apps in
the accordion, and only have the groups in it.

e.G.
Organiser, would contain: Addressbook, Tasks, Notes, Calendar
Crm: different crm apps, like: Leads, Calls, …
Erp: your apps

Would this fit for you?

Might work for me (I’ll discuss with the others around here), if the
groups can stay open until the user closes them, and if there’s only 1
app in the group (because of permissions), that should be handled
specially. Currently in the demo, as you go from one app to another
the tree disappears, which is fine for apps. For this to work well,
the user should be able to leave the groups they use often open.

Nathan Gray
nathan at goarctic dot com

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Lars_Kneschke-2 2008-02-05 21:23:45 UTC #6

“Nathan Gray” nathan@goarctic.com schrieb:

Might work for me (I’ll discuss with the others around here), if the
groups can stay open until the user closes them, and if there’s only 1
app in the group (because of permissions), that should be handled
specially. Currently in the demo, as you go from one app to another
the tree disappears, which is fine for apps. For this to work well,
the user should be able to leave the groups they use often open.

Everything is possible!

It is just an option for the accordion, that the other tabs get closed. If
we remove this option, the other tabs stay open.

But there are much more options we can choose from. The current solution is
not set in stone an we are open for any suggestions how to make it better.
Just post your ideas and will see how we can implement them.

–
Lars Kneschke
CTO OfficeSpot.Net
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg

eGroupWare Support: http://www.egroupware-support.net
OfficeSpot.Net Collaboration Server: http://cs.officespot.net
our proposal for the next major eGroupWare release: http://www.tine20.org

E-Mail: mailto:l.kneschke@metaways.de
Web: http://www.metaways.de
Tel: +49 (0)40 317031-21
Fax: +49 (0)40 317031-921
Mobile: +49 (0)175 9304324

Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Geschäftsführung: Hermann Thaele, Lüder-H.Thaele

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Raphael_Alla 2008-02-08 03:18:55 UTC #7

Hi,

it seems to me critical for Tine (and hopefully for egw too) to have a
proper CRUD framework and an easy way to represent data models. For blueerp,
I have built such a framework (called the ‘entity’ framework), which does
just that.

With regards to your question, I agree with Lars: defining from the main
object a {1:n:m} relationship does not make sense in the API because it
seems to me that each object should only know about its own content,
therefore the {1:n} and {0:m} relations are enough to define the model
adequately, isn’t it?

Cheers

“Nathan Gray” nathan@goarctic.com schrieb:

Much of pERP’s data is in 1:n:m relationships.
For example, 1 Order has {1,n} OrderLines, OrderLines have {0,m}
OrderLineDetails.
I’m wondering how the Tine Record_Interface would support such things,
and what the keys would look like?
Would each of Order, OrderLines, OrderLineDetails need to have an auto-
incrementing ID, or could multi-part keys like
{order_id, order_line_id, order_line_detail_id}
{1,0,0}, {1,1,0}, {1,1,1}, {1,1,2}, {1,2,0}, etc be used?

Hello Nathan!

The idea is to have a record. The record can have the following properties
for example:

description: datatype string
orderId: datatype integer
orderLines: datatype recordSet (containing multiple records)

The orderLines would be of the type Egwbase_Record. The recordSet contains
multiple objects of the same datatype(class instance of Egwbase_Record).
Inside the recordSet any record gets identified by its unique key.
Any items would have it’s own id, as the data are separated by different
classes.

If I understood your question correctly, I don’t think that we need
multi-part keys.

–
Lars Kneschke
CTO OfficeSpot.Net
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg

eGroupWare Support: http://www.egroupware-support.net
OfficeSpot.Net Collaboration Server: http://cs.officespot.net
our proposal for the next major eGroupWare release: http://www.tine20.org

E-Mail: mailto:l.kneschke@metaways.de
Web: http://www.metaways.de
Tel: +49 (0)40 317031-21
Fax: +49 (0)40 317031-921
Mobile: +49 (0)175 9304324

Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Geschäftsführung: Hermann Thaele, Lüder-H.Thaele

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Raphael Alla
Mitija Australia
+61 4 15 678 576
+687 78 86 86
http://www.mitija.com

Lars_Kneschke-2 2008-02-08 05:53:31 UTC #8

“Raphael Alla” raphael@mitija.com schrieb:

Hi,

it seems to me critical for Tine (and hopefully for egw too) to have a
proper CRUD framework and an easy way to represent data models. For
blueerp,
I have built such a framework (called the ‘entity’ framework), which does
just that.
Can you tell us more about it? I really like to share your ideas.

Since we have started working with the record thing, developing has become
much easier.

With regards to your question, I agree with Lars: defining from the main
object a {1:n:m} relationship does not make sense in the API because it
seems to me that each object should only know about its own content,
therefore the {1:n} and {0:m} relations are enough to define the model
adequately, isn’t it?
Yes. That’s also my idea. It also allows you to read only the data you need
and are not forced to read all data at once.

For a list view you don’t need to read all relationships at once from the
database. In most cases you only need to read all relationships when you
display/edit a record.

–
Lars Kneschke
CTO OfficeSpot.Net
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg

eGroupWare Support: http://www.egroupware-support.net
OfficeSpot.Net Collaboration Server: http://cs.officespot.net
our proposal for the next major eGroupWare release: http://www.tine20.org

E-Mail: mailto:l.kneschke@metaways.de
Web: http://www.metaways.de
Tel: +49 (0)40 317031-21
Fax: +49 (0)40 317031-921
Mobile: +49 (0)175 9304324

Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Geschäftsführung: Hermann Thaele, Lüder-H.Thaele

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Nathan_Gray-2 2008-02-08 15:09:41 UTC #9

With regards to your question, I agree with Lars: defining from the
main
object a {1:n:m} relationship does not make sense in the API
because it
seems to me that each object should only know about its own content,
therefore the {1:n} and {0:m} relations are enough to define the
model
adequately, isn’t it?
Yes. That’s also my idea. It also allows you to read only the data
you need
and are not forced to read all data at once.

For a list view you don’t need to read all relationships at once
from the
database. In most cases you only need to read all relationships when
you
display/edit a record.

That’s my thinking also, I just wanted to make sure that it was going
to be possible.

Nathan Gray
nathan at goarctic dot com

Extra punctuation??? Ug!!!
Just say no! Punctuation marks do not gain significance if you
increase their number, they make you look silly. One is sufficient.

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Raphael_Alla-2 2008-02-08 23:44:16 UTC #10

I am sure it did. Here are some thoughts on what I think is useful:

to define a number of relationships between entities of the data model
The relationship which I recommend are:

refers to: for instance, a timesheet can refer to a project, using the
project id. In this case my code allow the user to manipulate human readable
values (as returned by link_title) rather than project_id
has one or many {1:0…n}: for instance an invoice may have one or several
item lines. In this casen, the requirement is for the line item entity to be
able to refer to the invoice id.
many to many {n:n}: for instance, a project can refer to one or many
project members, and the project members can participate in several
projects. This relationship requires the use of a relationship table that
associates object id’s of both entities (in my example project_id and
contact_id)

to abstract the data model with an appropriate class, and provide generic
code (parent class) which handles relationship with the database and the
relationships between entities in a transparent way to the user. The
controller code never needs to deal with low level database issues
what I found useful too was to implement a unique object counter accross
entities, this way each object in the system has a unique id. This was
useful for cases where a single table is required to store several entitiess
which are similar, for instance customer and suppliers, while they have
different meanings, are really defined using the same set of data

Let me know what you think.

Cheers

Raphael

Lars_Kneschke-2 2008-02-09 09:14:39 UTC #11

“Raphael Alla” raphael.alla@gmail.com schrieb:

Since we have started working with the record thing, developing has
become

much easier.
…

to define a number of relationships between entities of the data model
The relationship which I recommend are:

refers to: for instance, a timesheet can refer to a project, using the
project id. In this case my code allow the user to manipulate human
readable
values (as returned by link_title) rather than project_id

has one or many {1:0…n}: for instance an invoice may have one or
several
item lines. In this casen, the requirement is for the line item entity to
be
able to refer to the invoice id.

many to many {n:n}: for instance, a project can refer to one or many
project members, and the project members can participate in several
projects. This relationship requires the use of a relationship table that
associates object id’s of both entities (in my example project_id and
contact_id)
If I see it correctly, we have different requirements, which result from the
chosen concept(rendering on server side or client side). It might also be
just a misunderstanding.

For Tine 2.0 I have seen only one place in the PHP code, where we need to
have ALL data of ONE record. That’s the case when we are about to deliver
the data for ONE record to the user interface. In this case we prepare the
data to be displayed at the JSON client(the webbrowser). And there we have a
media disruption. We loose any logic(PHP !== Javascript) and transport only
the data. So it makes not much sense for us to have to much logic in the
Egwbase_Record. Either we know which data should get delivered to the JSON
client or we know what to do with the data in the controller of the
application.

That’s really difficult to explain. But developing for a Javascript/JSON
interface really changes the way you need to think about data strcutures.

to abstract the data model with an appropriate class, and provide
generic
code (parent class) which handles relationship with the database and the
relationships between entities in a transparent way to the user. The
controller code never needs to deal with low level database issues
That’s exactly the way we have implemented for tine. Any applications
communicate only using the controller with each other. In most cases all
data exchange between the controllers are instances of Egwbase_Record or
Egwbase_RecordSet. The Egwbase_Record has build in dateconverting and
validation of data.
This way we can validate at any step in the Tine 2.0 code, that the data we
are working are valid.

But we haven’t tied it to the database. Our data class only handles data,
but does not know about the backend. Suppose you want to create a new empty
contact, which should get delivered to the JSON client. Will you store it in
ldap or sql. Will you ever store it? Or just deliver a empty contact to the
JSON client?

what I found useful too was to implement a unique object counter
accross
entities, this way each object in the system has a unique id. This was
useful for cases where a single table is required to store several
entitiess
which are similar, for instance customer and suppliers, while they have
different meanings, are really defined using the same set of data
We also thought about this. Our idea was to assign a unique identifier to
any entity stored in the database and use this as the primary key in the
database. We just had not the time to finalize our thoughts.
–
Lars Kneschke
CTO OfficeSpot.Net
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg

eGroupWare Support: http://www.egroupware-support.net
OfficeSpot.Net Collaboration Server: http://cs.officespot.net
our proposal for the next major eGroupWare release: http://www.tine20.org

E-Mail: mailto:l.kneschke@metaways.de
Web: http://www.metaways.de
Tel: +49 (0)40 317031-21
Fax: +49 (0)40 317031-921
Mobile: +49 (0)175 9304324

Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Geschäftsführung: Hermann Thaele, Lüder-H.Thaele

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers