Hello Anthony, hello Franck,

Thank you, i now understand the 3.x concept for foreign keys.

Ciao, Guenter

Hi,

as Anthony pointed it Payroll is a good example.

You won't use the SFieldReference itself as part of the empoyee's pk,
but will use the SFieldScalar used in the reference as part of the pk.

eg :

class Department extends SRecordInstance {
(...)
public static SFieldString deptid = new SFieldString(meta, "deptid",
SPRIMARY);
(...)
}

class Employee extends SRecordInstance {
(...)
public static SFieldString emp_deptid = new SFieldString(meta, "deptid",
SPRIMARY);
public static SFieldString empid = new SFieldString(meta, "empid",
SPRIMARY);
(...)
public static SFieldReference<Department> dept = new
SFieldReference<Department>(meta, Department.meta, new
SFieldScalar[]{emp_deptid}, new SFieldScalar[]{Department.deptid});

}


HTH

Franck


Le vendredi 18 décembre 2009 à 17:29 +1000,
berglas@... a écrit :
>
> Just mark the referencing columns as part of the foreign key. Under
> Franck's simplification there is no longer any nesting of foreign
> keys. Have a look at payroll.java.
>
> Anthony
>
> At 04:45 PM 18/12/2009, you wrote:
> >
> >
> >Hello!
> >
> >How do i define a foreign key as a part of the primary key?
> >For the Empoyee-example this would mean the reference to the
> department
> >would be part of the primary key of employee.
> >Thank you in advance.
> >
> >Ciao, Guenter
> >
> >
>
> Spreadsheet Detective,
> Southern Cross Software Queensland Pty Limited
> 54 Gerler Street
> Bardon, Queensland 4065, Australia.
>
> Email: berglas@...
> www.SpreadsheetDetective.com
> Ph: +61 427 830248 (Australian Eastern Standard Time)
>
> "If the model seems correct only because the numbers look right,
> then why build the model in the first place?"
>
>
>
>

Just mark the referencing columns as part of the foreign key.  Under Franck's
simplification there is no longer any nesting of foreign keys.  Have a look at
payroll.java.

Anthony

At 04:45 PM 18/12/2009, you wrote:
>
>
>Hello!
>
>How do i define a foreign key as a part of the primary key?
>For the Empoyee-example this would mean the reference to the department
>would be part of the primary key of employee.
>Thank you in advance.
>
>Ciao, Guenter
>
>


Spreadsheet Detective,
Southern Cross Software Queensland Pty Limited
54 Gerler Street
Bardon, Queensland 4065, Australia.

Email: berglas@...
www.SpreadsheetDetective.com
Ph: +61 427 830248 (Australian Eastern Standard Time)

"If the model seems correct only because the numbers look right,
then why build the model in the first place?"

Hello!

How do i define a foreign key as a part of the primary key?
For the Empoyee-example this would mean the reference to the department
would be part of the primary key of employee.
Thank you in advance.

Ciao, Guenter

Not normally necessary.  And locking is about more than Synchronized.  Unlike
most software, SimpleORM takes care to try to fail fast if you have threading
errors.

Anthony

At 05:35 PM 9/11/2009, you wrote:
>
>
>Hello Anthony,
>Thanks for the reply and I have to say I do understand exactly what you mean.
What I am really concerned with is whether I may have to write synchronised
methods to restrict how resources are accessed. Is this really necessary while
using this package.
>
>On Sun, Nov 8, 2009 at 4:14 AM,
<<mailto:anthony@...>anthony@...> wrote:
>
>
>SimpleORM checks for common threading errors such as trying to use the same
*Connection* from two threads.
>
>It is quite OK and normal to have multiple threads in multiple JVMs accessing
the same database, with each thread having its own connection.
>
>But keeping accesses from different connections from interfering is the job of
the database. In normal usage, with normal locking, you should be OK. And
SimpleORM double checks all updates with optimistic locks. But the details can
be very complex. The white paper has a section.
>
>Anthony
>
>
>At 01:31 PM 7/11/2009, you wrote:
>>
>>
>>Hello all.
>>I have been using SimpleORM for a few months now and it has been a
>>great help especially for backend data migration scripts. I shall be
>>writing my first full app in about 2 months time. I have been reading
>>a lot on thread safety and I wanted to know whether the
>>getThreadLocalSession method is enough to ensure thread safety when
>>accessing the db or whether I need to have my own implementation to
>>ensure that if 30 people or so are connected actions such as inserting
>>data to the db are safe and data integrity is maintained. Kindly
>>advise. Kind regards. Abel
>>
>
>Dr Anthony Berglas, <mailto:anthony%40berglas.org>anthony@... Mobile:
+61 4 4838 8874
>Just because it is possible to push twigs along the ground with ones nose
>does not necessarily mean that is the best way to collect firewood.
>
>
>

Dr Anthony Berglas, anthony@...       Mobile: +61 4 4838 8874
Just because it is possible to push twigs along the ground with ones nose
does not necessarily mean that is the best way to collect firewood.

If you have non-trivial queries for MSSQL try

UPDATE STATISTICS

on the main tables.  I have found that sometimes it just looses track and starts
running slowly for no apparent reason.

Anthony

At 01:18 PM 7/11/2009, you wrote:
>
>
>Thanks for the feedback!  Right now the database is responsible for basically
100% of the run time because the main thread (which is actually querying the
dataset, not the database) is always faster than the database query thread.  So
there's no point speeding up findUsingPrototype (used in the main thread)
anymore until we get the database query thread working faster.
>
>But that could just be because something odd is happening over in SQL Server. 
For now, we're able to blame Microsoft for our problems.
>
>Maybe we'll try HSQLDB.  I wasn't aware that it did hybrid disk/memory
operations (our 65 million records will NOT fit into memory all at once), and I
wasn't aware that it could process .CSV files directly.  Those two features
together with a potential speed advantage make it look very promising.  Our
users like .CSV files for the smaller tables.
>
>--
>John
>
>
>On 6-Nov-09, at 7:19 PM, <mailto:anthony@...>anthony@... wrote:
>
>>Hello John,
>>
>>THREADING
>>
>>Your threading approach is OK.
>>
>>In normal operation, you would have one session per thread, one thread per
session. This can be overridden in special cases, but normally there are sanity
checks to ensure that it is the case. Sharing a JDBC connection between threads
is certainly asking for deep trouble.
>>
>>Queing the SDataSets is a reasonable approach. There are examples in the
LongTransactionTest as to how to detach and reattach SDataSets.
>>
>>An alternative would be to simply have two threads, each of which does the
reading and the processing, and then synchronize to ensure that only one ever
does critical processing at a time. Avoids need for a queue.
>>
>>But generally, I would not introduce complex architectures for maximum gain of
only 30%.
>>
>>More importantly, can the processing itself be multi threaded? You have not
indicated the application, so hard for me to know. But a quad core machine might
increase throughput by 400%, much better than 30% improvement.
>>
>>One way to go much faster is to use a Java embeded database. HSQL, for example
can be well over 1000% faster than Oracle. Daffodil, H2 and JavaDB are probably
more reliable, have not tested for speed. But again, if the database is only
consuming 30% of your time,
>>
>
>Dr Anthony Berglas, anthony@...       Mobile: +61 4 4838 8874
>Just because it is possible to push twigs along the ground with ones nose
>does not necessarily mean that is the best way to collect firewood.