Re: dynamic table name

Hi Anthony,

thanks for the quick reply, you suggestion has actually helped me 
quite a lot. The only problem I needed to solve was to be able to 
design something that can receive the table name in both static and 
non static methods. The idea came to me from your ThreadLocal usage 
for connection management. I construct a meta object using the 
desired tablename and then attach it to threadlocal so that both 
static and non-static methods can use it. This worked like just fine.

Maybe someone can suggest an easier way of doing this?

I am including the actual class I created in case someone else might 
fall into this scenario (no point of re-inventing the wheel).

Thank you again for your help.
PS are there any plans for a new release of simpleorm?

-------------------------------------------------------------------

import java.util.*;
import java.sql.*;

import simpleorm.core.*;
import simpleorm.properties.*;

public class Content extends SRecordInstance
{
  /**
   * Thread's meta object

Re: SFieldReference necessary

Should be OK, but look at the examples to see how to do it correctly. 
You do not want to end up with fields declared twice.

Anthony

Alexander Banthien wrote:

> Hi all,
> 
> I just stumbled accros something and would like to hear I am on the 
> right track. I reverse engineered my classes from the DB using 
> SimpleORMGenerate. That tool does not at all create SFieldReferences but 
> only SFieldLongs (or whatever type the keys are) and autocodes getters 
> and setters to do the object navigation (Employee.getDepartment()). (as 
> documented in the corresponding package.html)
> 
> Is it advisable to use SFieldReferences over plain fields or doesn't it 
> matter? (all assuming I don't intend to forward engineer my database 
> schema from the SimpleORM classes) Performace? stability? ...
> 
> Alexander
> 

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/5cFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

Re: computed column values

I think you've said it all well.  The third approach would be a bit 
faster, but consider whether that is really important to you.

Be very careful using database triggers that update things.  They can 
cause havoc when doing unrelated maintenance, eg. loading a table from 
an external source.

Anthony.

Alexander Banthien wrote:

> Hi,
> 
> I recently ran into a little problem. I propose a solution and a small 
> hack to SimpleORM as solution. At the core it is about emulating the 
> following SQL
> 
> select TITLE, ( select sum(AMOUNT) from B where A.pkA=B.fkA) TOTAL from 
> A where ...
> 
> 1. Background
> To make an example we have a table INVOICE and a table PAYMENT an 
> invoice entity may be paid in several payments. We would like the 
> invoice object to carry a sum over all the payments done so far. (Web 
> application, ASP.NET, SQL Server)
> 
> 2) Solutions
> Solution 1: implement a method
> A method getTotal() could be written on the Invoice-class to do a query 
> on PAYMENT and calculate the total. Simple enough, straight forward.

Why Call nextGeneratedValue() on SFieldMeta from SDriverOracle ?

Re: Digest Number 318

Hello

I usualy use this description and it works well with henerated keys

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
package model;

import simpleorm.core.*;
import simpleorm.properties.*;

public class SVeiksmas extends SRecordInstance { // ie. a class mapped to a
table.

  public static final SRecordMeta meta  = new SRecordMeta(SVeiksmas.class,
"HIP.VEIKSMAI");

  public static final SFieldInteger VEI_ID = new SFieldInteger (meta,
"VEI_ID",
      new SPropertyValue[]{ SFD_PRIMARY_KEY, SFD_GENERATED_KEY,
SSEQUENCE_NAME.pvalue("HIP.hip_veiksmai_id_seq")});

  public static final SFieldInteger VEIK_TIPAS =  new
SFieldInteger(meta,"VEIK_TIPAS");

  public SRecordMeta getMeta() { return meta; };
}
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

in what version you have nextGeneratedValue() on SFieldMeta from
SDriverOracle ?

Best regards,
Linas

----- Original Message ----- 
From: <SimpleORM <at> yahoogroups.com>
To: <SimpleORM <at> yahoogroups.com>
Sent: Friday, July 09, 2004 10:29 AM
Subject: [SimpleORM] Digest Number 318

>
> There is 1 message in this issue.
>
> Topics in this digest:
>
>       1. Why Call nextGeneratedValue() on SFieldMeta from SDriverOracle ?
>            From: Oliver Eiholzer <Oliver.Eiholzer <at> steria.ch>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 1
>    Date: Thu, 8 Jul 2004 11:55:27 +0200
>    From: Oliver Eiholzer <Oliver.Eiholzer <at> steria.ch>
> Subject: Why Call nextGeneratedValue() on SFieldMeta from SDriverOracle ?
>
> Hi all,
>
> Does anyone know why the nextGeneratedValue() method on SFieldMeta is
called
> from SDriverOracle ?
> In my opinion this is not needed since oracle has sequences. Because the
> lastGeneratedKeyValue is cached by SFieldMeta is cached we have serious
> problems (ORA-00001 Unique Constraint violation).
>
> And that's how it happens:
> (Sequence starts with 1, increment 1)
>
> Steps
lastGeneratedKeyValue
> variable | CURRVAL of Sequence in Schema One | CURRVAL of Sequence in
Schema
> Two
> 0.
> 0 1
> 1
> 1. ALTER SESSION SET CURRENT_SCHEMA = One
> 2. Insert record                                                2
> 2                          1
>
> 3. Insert record                                                3
> 3                          1
> 4. ALTER SESSION SET CURRENT_SCHEMA = Two
> 5. Insert record                                                4!!
> 3                          2
>
> 6. Restart Server
> 0 3
> 2
> 7. ALTER SESSION SET CURRENT_SCHEMA = Two
> 8. Insert record
> 3 3
> 3
> 9. Insert record -> Unique Constraint violation because
sequenceTwo.nextval
> returns 4 but dthis ID was already used on step 5.
>
> This code in SFieldMeta causes the troubles:
>   synchronized long nextGeneratedValue(long minimum) {
>     if (lastGeneratedKeyValue < minimum)
>       lastGeneratedKeyValue = minimum;
>     else
>       ++lastGeneratedKeyValue;
>     return lastGeneratedKeyValue;
>   }
>
> Bevor I patch the SDriverOracle class i would like to know why it calls
the
> nextGeneratedValue() method.
>
> Any Ideas?
>
> regards,
>
> oliver
>
> -----Original Message-----
> From: Anthony & Melissa Berglas
> [mailto:berglas <at> SpreadsheetDetective.com]
> Sent: Mittwoch, 7. Juli 2004 06:37
> To: SimpleORM <at> yahoogroups.com
> Subject: Re: [SimpleORM] SFieldReference necessary
>
>
> Should be OK, but look at the examples to see how to do it correctly.
> You do not want to end up with fields declared twice.
>
> Anthony
>
> Alexander Banthien wrote:
>
> > Hi all,
> >
> > I just stumbled accros something and would like to hear I am on the
> > right track. I reverse engineered my classes from the DB using
> > SimpleORMGenerate. That tool does not at all create SFieldReferences but
> > only SFieldLongs (or whatever type the keys are) and autocodes getters
> > and setters to do the object navigation (Employee.getDepartment()). (as
> > documented in the corresponding package.html)
> >
> > Is it advisable to use SFieldReferences over plain fields or doesn't it
> > matter? (all assuming I don't intend to forward engineer my database
> > schema from the SimpleORM classes) Performace? stability? ...
> >
> > Alexander
> >
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
> [This message contained attachments]
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
>
>
> ------------------------------------------------------------------------
> Yahoo! Groups Links
>
>
>
>
> ------------------------------------------------------------------------
>

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/5cFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> To unsubscribe from this group, send an email to:
    SimpleORM-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

RE: Digest Number 318

Limitations .NET / MSSQL ?

hi everybody,

after getting into work with SimpleORM (MSSQL, ASP.NET using a DSN (this 
ODBC)) here are the 3 issues that are annoying our team (VB and Java 
people, VS.NET users) most:

1) It seems impossible to have two SResultSets open at one given point 
in time. That is ugly because
while (res.hasNext) {
    ((Employee) res.getRecord()).getRefDepartment()
}
does not work, if the Departments are not already in the transaction cache.
Moreover it makes "long running" transactions accross several clicks on 
the web page ugly because any DML or even SELECT will fail if another 
Connection is already associated with the current thread. (e.g. stored 
in the Session)

2) Debugging is very cumbersome in VS.NET as it is not possible to see 
the field values (unless they are Strings) of the entity classes, not 
even Longs are displayed by the VS.NET Debugger as they are 
java.util.Long which seemingly are not displayed by VS.NET as opposed to 
System.Int64, which are.

3) I have so far failed to implement the entity classes in VB. They only 
work in J# and cannot be derived from. I am pretty certain this is my 
own fault, but I just didn't manage to get it done. Can someone provide 
some example code?

Now my questions to the Wizards on the list: are these problems well 
known? am I doing something wrong? what can I do as remedy?

Sidenote: the problem is a bit pressing, because my team is loosing 
faith in SimpleORM. I find it extraordinarily well thought out, well 
designed, well written. But the issues raised above are quite valid; 
they have cause significant standstill in development.
I would love to continue with SimpleORM because I find it conceptually 
superior to everything else I know and we have already invested 
significant development work into it. But unless we can improve its 
useability in .NET I am afraid we will have to replace it.

Thank you all for your attention and for any replies

Alexander

-- 
---------------------
Alexander Banthien
---------------------

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/5cFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> To unsubscribe from this group, send an email to:
    SimpleORM-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

good practice: creating objects in long running transactions, ID broker

Hi all,

may I ask advice on the following problem. We intend to put together a 
number of objects during a transaction that shall span a number of 
clicks in a web application (wizard style). (in concreto: it is a 
payment wizard and we are collecting the data for the payment records, 
ASP.NET, MSSQL)

Out of the box, SimpleORM doesn't seem to offer a solution to this, 
since the Payment table is locked and cannot even be read from until the 
payment records are flushed which may be a very long time in a web 
scenario. That seems to be one of the drawbacks of the SELECT MAX method 
for ID generation.

A possible solution is:
 Implement an ID-broker:
The ID-Broker would read from the equivalent of an Oracle Sequence (we 
are on MS SQL, no sequences) and use the generated Ids as next IDs.
Problems: produces gaps (well, any solution does), no good control over 
integrity of ID generation when 3rd parties accessing.
Advantages: fast, caching a batch of IDs may improve performance even more.

It should be noted that the ID-Broker may not run within the same 
transaction as do the entity objects! rather a raw query should be used 
outside SimpleORM because otherwise the same locking issues will arise.

Is my reasoning right? have people implemented IDBrokers? with good 
success? other strategies?

TIA, Alexander

-- 
---------------------
Alexander Banthien
ParentPay Ltd.
Project Manager
+49 (0)7024 4675431
---------------------

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/5cFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> To unsubscribe from this group, send an email to:
    SimpleORM-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: good practice: creating objects in long running transactions, ID broker

So how about you ask the basic information in the first form -- enough 
to get a good natural key and then just create the record, possibly with 
a status "pending".  Commit this.

Then treat the other pages as updates to this transaction.

If someone starts again, then you can show them a list of pending and 
completed transactions.   Give users the ability to navigate between 
forms in the order they choose (as much as possible) -- don't be a facist.

This means that if they abandon the multi form system at any stage, they 
can just keep going from where they left off.

The alternative is to put everything into session state, using the long 
transaction facility (ie. optimistic locks).  But I do not like using 
applications like this -- especially if there is a problem half way 
through and I have to re-enter all the previous data again!

Also, I personally would much prefer to work with one form of 20 fields 
than 10 forms each with 2 fields.

Anthony

Alexander Banthien wrote:

> Hi all,
> 
> may I ask advice on the following problem. We intend to put together a 
> number of objects during a transaction that shall span a number of 
> clicks in a web application (wizard style). (in concreto: it is a 
> payment wizard and we are collecting the data for the payment records, 
> ASP.NET, MSSQL)
> 
> Out of the box, SimpleORM doesn't seem to offer a solution to this, 
> since the Payment table is locked and cannot even be read from until the 
> payment records are flushed which may be a very long time in a web 
> scenario. That seems to be one of the drawbacks of the SELECT MAX method 
> for ID generation.
> 
> A possible solution is:
>  Implement an ID-broker:
> The ID-Broker would read from the equivalent of an Oracle Sequence (we 
> are on MS SQL, no sequences) and use the generated Ids as next IDs.
> Problems: produces gaps (well, any solution does), no good control over 
> integrity of ID generation when 3rd parties accessing.
> Advantages: fast, caching a batch of IDs may improve performance even more.
> 
> It should be noted that the ID-Broker may not run within the same 
> transaction as do the entity objects! rather a raw query should be used 
> outside SimpleORM because otherwise the same locking issues will arise.
> 
> Is my reasoning right? have people implemented IDBrokers? with good 
> success? other strategies?
> 
> TIA, Alexander
> 

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/5cFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> To unsubscribe from this group, send an email to:
    SimpleORM-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Limitations .NET / MSSQL ?

Hello Alexander,

I have not worked on the .Net version, although I will.

1. There is an issue with getRefDepartement if res is detached, but it 
should work fine otherwise.  Are you sure that the problem is really 
having two result sets open at once?  What happens if you get an 
employee in one loop, close the result set, and then getRefDepartment?

(If it is easy for you to get this working in Java (not j#) then that 
would be helpful.)

Sylvain can probably help here.

2. I suspect that there are actually three Long data types in .net. 
There is int64, which is a value type, Boxed Longs which are just 
declared object, and java.lang.Long.  It is a pain that .net boxed longs 
do not have an explicit data type, one would sometimes like to declare a 
parameter that way.

One solution is to simply add properties to your records that return 
long instead of Long, ie. value types.  But you would need to be careful 
about nulls.  Maybe a method like

function netLong(jlong as java.lang.Long) as object
   if jlong is nothing then return null
   dim vlong as int64
   vlong = jlong.longValue()
   return (object)vlong
end function

Please let me know if this works.

There is an issue in that unlike J#, C# & VB.Net do not allow constants 
to be declared in interfaces.  So you need to qualify them with the 
interface name.  I think I have already described this, have a look on 
the list.

Hope this helps, but Sylvain is the .Net guru.

Anthony

Alexander Banthien wrote:

> hi everybody,
> 
> after getting into work with SimpleORM (MSSQL, ASP.NET using a DSN (this 
> ODBC)) here are the 3 issues that are annoying our team (VB and Java 
> people, VS.NET users) most:
> 
> 1) It seems impossible to have two SResultSets open at one given point 
> in time. That is ugly because
> while (res.hasNext) {
>     ((Employee) res.getRecord()).getRefDepartment()
> }
> does not work, if the Departments are not already in the transaction cache.
> Moreover it makes "long running" transactions accross several clicks on 
> the web page ugly because any DML or even SELECT will fail if another 
> Connection is already associated with the current thread. (e.g. stored 
> in the Session)
> 
> 2) Debugging is very cumbersome in VS.NET as it is not possible to see 
> the field values (unless they are Strings) of the entity classes, not 
> even Longs are displayed by the VS.NET Debugger as they are 
> java.util.Long which seemingly are not displayed by VS.NET as opposed to 
> System.Int64, which are.
> 
> 3) I have so far failed to implement the entity classes in VB. They only 
> work in J# and cannot be derived from. I am pretty certain this is my 
> own fault, but I just didn't manage to get it done. Can someone provide 
> some example code?
> 
> Now my questions to the Wizards on the list: are these problems well 
> known? am I doing something wrong? what can I do as remedy?
> 
> Sidenote: the problem is a bit pressing, because my team is loosing 
> faith in SimpleORM. I find it extraordinarily well thought out, well 
> designed, well written. But the issues raised above are quite valid; 
> they have cause significant standstill in development.
> I would love to continue with SimpleORM because I find it conceptually 
> superior to everything else I know and we have already invested 
> significant development work into it. But unless we can improve its 
> useability in .NET I am afraid we will have to replace it.
> 
> Thank you all for your attention and for any replies
> 
> Alexander
> 

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/5cFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> To unsubscribe from this group, send an email to:
    SimpleORM-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/