Db4o en andere OO Databases

[H!GHGuY]

Aangezien mijn topic⁽¹⁾ over NHibernate zo maar niet uit het slop geraakt en ik niet zeker ben of NHibernate al mijn keuzes wel mooi kan waarmaken ben ik ook op zoek naar andere manieren om mijn data te serializeren.

Een van de nadelen van NHibernate is dat je een DBMS moet draaien. Ik dacht al aan SQLite wat voor een desktop applicatie ruim voldoende zou zijn; Zeg nu zelf: een heuse MySQL, Ms SQL of andere DB draaien enkel om een taakplanner tool te draaien was me toch iets teveel.

Mijn oog viel daarbij, via Wikipedia⁽²⁾ op Db4o ⁽³⁾. Na me wat ingelezen te hebben besloot ik om de .NET 3.5 versie te downloaden en te installeren. Daarna heb ik de tutorial doorgenomen en ik was behoorlijk verbaasd over de mogelijkheden.

Bvb:
- Zeer eenvoudige interface
- Transparent activation (Vergelijkbaar met NHibernate lazy-loading)
- Transparent persistence (Automatisch persistence van objecten tijdens aanroep van een "globale" Commit() functie)
- LINQ integratie
- Zowel Java als .NET support

Natuurlijk is een tutorial een mooi verkoopspraatje en vroeg ik me af of andere mensen reeds ervaringen hebben met Db4o of andere OODBMS'en. Hier op GoT zag ik Gerco al enkele malen db4o voorstellen in allerhande topics, maar daar werd verder weinig aanbod besteed aan de DB.

Naarmate ik ervaringen met deze DB opdoe, (ik ben nl. wegens de NHibernate historie even van scratch herbegonnen, maar dan wel formeler) kan ik gerust mijn eigen ervaringen posten.

⁽¹⁾ [NHibernate] mapping van interfaces en hun implementors
⁽²⁾ Wikipedia: Comparison of object database management systems
⁽³⁾ http://www.db4o.com/

[urk_forever]

Hoe moet ik zoiets zien een OO database? Ken je dan ook de structuur met tabellen etc, alleen dat je ook makkelijk een veel op veel relatie kan definieren of gaat het verder dan dat?

Of is dat helemaal weg en kan je gewoon al je objecten in de database stoppen?

[beany]

urk_forever schreef op maandag 15 juni 2009 @ 21:32:
Of is dat helemaal weg en kan je gewoon al je objecten in de database stoppen?

Yep!

Een grote speler op de markt van OO databases is overigens InterSystems(product heet Caché). Maar het is wel wat prijzig. Maar dit om er een groot product bij te zetten. Voor het perspectief zeg maar

DB4O kan overigens ook als standalone server gedraaid worden, al heb ik dit zelf nog nooit gedaan. Het project is nog niet volwassen(in mijn optiek) maar ze zijn zeker op de goede weg!

[GrooV]

Hoe snel is het dan met een database met 100miljoen records bijvoorbeeld?

[Gerco]

beany schreef op maandag 15 juni 2009 @ 21:36:
Een grote speler op de markt van OO databases is overigens InterSystems(product heet Caché). Maar het is wel wat prijzig. Maar dit om er een groot product bij te zetten. Voor het perspectief zeg maar

Ik heb wat beperkte ervaring met Caché en het bevalt me wel. Het is oorspronkelijk ontstaan uit een ver ontwikkelde versie van MUMPS, maar daar zie je eigenlijk niets meer van. Het is nog wel mogelijk om dat soort code te schrijven.

De database is via een object interface te benaderen (met cache objectscript), via SQL met ODBC en door direct de "globals" te benaderen. Die laatste methode is niet aan te raden als je compatibiliteit wilt bewaren met de andere twee interfaces. Je kunt er namelijk dingen mee die niet in SQL of ObjectScript uit te drukken zijn.

InterSystems heeft overigens ook een ESB produkt (Ensemble), wat bovenop Caché gebouwd is. Dat geeft het wat interessante eigenschappen die in andere ESBs soms erg moeilijk te verkrijgen zijn (zoals transparante message persistence en tracing).

DB4O kan overigens ook als standalone server gedraaid worden, al heb ik dit zelf nog nooit gedaan. Het project is nog niet volwassen(in mijn optiek) maar ze zijn zeker op de goede weg!

Daar ben ik het helemaal mee eens. Een grote misser in db4o voor de OSS ontwikkelaar was altijd dat er voor de tooling betaald moest worden. De Object Manager is inmiddels gratis geworden (voor java dan toch), maar ik heb nadat dat gebeurd is eigenlijk niet meer met db4o gewerkt.

Ik weet wel dat het gebrek aan goede tooling me ervan weerhouden heeft om het voor grotere projecten in te zetten dan een gemiddelde hobby crud app maar die mening is waarschijnlijk aan herziening toe.

[ Voor 7% gewijzigd door Gerco op 15-06-2009 22:15 ]

[TeeDee]

GrooV schreef op maandag 15 juni 2009 @ 21:40:
Hoe snel is het dan met een database met 100miljoen records bijvoorbeeld?

Ten 1e: Puur op basis van de scope van de TS (een taakplanner tool) is dat niet relevant.
Ten 2e: Ook andere DBMS'sen zouden met 100 miljoen records een beetje moeilijk doen.
Ten 3e: Dat je niet om de performance van 1000 miljoen records vraagt
Ten 4e: Als je een DB van 100 miljoen records hebt zal je imo wat gerichter onderzoek doen dan hier even wat vragen.
Ten 5e: ze hebben best een indrukwekkende lijst met klanten... die hebben ze niet zomaar.

Wat betreft doorslaggevende benchmarks etc. moet ik je een antwoord schuldig blijven. Alles valt en staat met configuratie en de manier van benchen. Meten is weten en vaak doe je dat zelf in je eigen cases het beste.

Even ontopic nog:
Heb zelf nog geen ervaring met 'pure' OO DBMS-en, maar op een of andere manier ben ik gehecht aan de abstractie die een LLBLgen bijvoorbeeld geeft. Neemt niet weg dat het uiteraard een interessant iets is om te bekijken/testen.

[ Voor 26% gewijzigd door TeeDee op 15-06-2009 22:49 ]

[GrooV]

Sorry misschien was mijn vraag aan de korte kant, ik zal het anders formuleren. Blijft de database nog snel (inverhouding tot bijv. mysql) wanneer er steeds meer data in komt?

[ Voor 8% gewijzigd door GrooV op 15-06-2009 23:17 ]

[RobIII]

Waar ik wel een beetje 'bang voor ben' bij DB's als DB4O is zaken als recusive updates en deletes.

Uit hun tutorial haal ik bijvoorbeeld (4.4.2):

code:

IObjectSet result = db.QueryByExample(new Pilot("Michael Schumacher", 0));
Pilot pilot = (Pilot)result.Next();
Car car1 = new Car("Ferrari");
Car car2 = new Car("BMW");
car1.Pilot = pilot;
car2.Pilot = pilot;
db.Store(car1);
db.Store(car2);
db.Delete(car2);

Houston, we have a problem - and there's no simple solution at hand. Currently db4o does not check
whether objects to be deleted are referenced anywhere else, so please be very careful when using this feature.

In dit geval is de "pilot" van car 1 foetsie terwijl er wel degelijk een reference bestaat. Nu kun je met wat voorzichtig en doordacht programmeren wel om dit soort zaken heen werken maar ik vind 't doodeng en DB4O zou dat in feite "voor je" moeten doen Het hele "joepie, een complete object hiërarchie in 1 keer opslaan"-effect is dan meteen foetsie bij mij. Het hele "Relational" deel van een RDBMS mis ik dus.

Tevens vind ik de IActivator interface voor lazy-loading nogal omslachtig werken; hoewel het (zo ver ik kan bedenken) een goede oplossing is om lazy-load generiek te implementeren vind ik 'm teveel "in your face" en overal-en-nergens opduiken in je code.

[ Voor 31% gewijzigd door RobIII op 15-06-2009 23:59 ]

[cariolive23]

GrooV schreef op maandag 15 juni 2009 @ 21:40:
Hoe snel is het dan met een database met 100miljoen records bijvoorbeeld?

Op deze vraag is onmogelijk een antwoord te geven, er zijn veel te veel factoren die invloed hebben op een mogelijk antwoord.

100 miljoen keer vrijwel niks, is nog steeds vrijwel niks. Wanneer je echt 1000 keer 1 GB data in een record hebt staan, dan heb je mogelijk een veel grotere uitdaging dan wanneer je met 100 miljoen integers aan de slag gaat.

Ook het aantal concurrent users heeft grote invloed op de performance. Tweakers heeft een aantal keren MySQL en PostgreSQL getest op diverse platformen. MySQL 5.0 (die toch bekend staat om snelheid) bleek veel langzamer te worden wanneer er meer dan 5 concurrent users op de database zaten. PostgreSQL begon dan net op stoom te komen en ging dan pas echt performance leveren.

Verder heeft ook het gebruik van de database invloed op de performance, heb je 1 record nodig of heb je grote recordsets nodig? En hoe haal je die sets op? Vele OO-programmeurs halen hun objecten 1-voor-1 op uit de database, dat worden dan al snel vele duizenden losse queries daar waar je wellicht ook met 1 of enkele queries klaar zou kunnen zijn.

De snelheid van een database is afhankelijk van een zeer groot aantal factoren, je kunt niet zomaar stellen dat de ene database sneller is dan de andere. Zelfs niet wanneer ze met dezelfde applicatie werken, de ene database kan beter uit de voeten met een bepaalde structuur dan dat de andere database dat kan.

Wel leuk om eens een toepassing van een OO-database te zien. OO en RDBMS-en zijn imho geen groot succes, de vertaalslag is niet efficient waardoor je van beide werelden de beste eigenschappen verliest en je dus met een middelmatige oplossing blijft zitten.

[whoami]

Mja, ik heb geen ervaring met OO databases, maar ik blijf het concept wel vreemd vinden.
OO is goed om data + behaviour voor te stellen; een DB slaat enkel data op. Daarbij vind ik het relationeel model nog steeds de beste manier om data in op te slaan; bijkomend voordeel is dat je er snel ad-hoc queries kan op loslaten, zonder dat je aan je OO model gebonden bent.

Daarbij denk ik wel dat je manier in NHibernate mogelijk moet zijn; als ik ooit eens 5 minuten tijd heb zal ik eens iets proberen.

/hoop dat ik het topic nu niet teveel ontspoord heb.

[EfBe]

H!GHGuY schreef op zaterdag 13 juni 2009 @ 12:24:
Aangezien mijn topic⁽¹⁾ over NHibernate zo maar niet uit het slop geraakt en ik niet zeker ben of NHibernate al mijn keuzes wel mooi kan waarmaken ben ik ook op zoek naar andere manieren om mijn data te serializeren.

Ik begrijp niet echt waarom je niet gewoon je probleem oplost op een manier die het probleem oplost. Het riekt er een beetje naar dat je per se een bepaalde oplossing wilt en daar alles voor moet wijken. Dat is de omgekeerde wereld.

Een van de nadelen van NHibernate is dat je een DBMS moet draaien. Ik dacht al aan SQLite wat voor een desktop applicatie ruim voldoende zou zijn; Zeg nu zelf: een heuse MySQL, Ms SQL of andere DB draaien enkel om een taakplanner tool te draaien was me toch iets teveel.

Een database is een systeem om data te ontsluiten. de data is opgeslagen in bestanden, en hoe dat gebeurt is aan het database systeem. Hoe meer features, hoe groter het systeem. Als je alleen maar een paar tabellen hebt, dan is wellicht sqlite een leuke oplossing, of anders firebird embedded. let wel: dat zijn net zo goed databases als alle andere, ze hebben wellicht wat minder features, maar op zich boeit dat voor een kleine applicatie niet zo.

Dus waarom heb je die andere databases niet gekozen?

Mijn oog viel daarbij, via Wikipedia⁽²⁾ op Db4o ⁽³⁾. Na me wat ingelezen te hebben besloot ik om de .NET 3.5 versie te downloaden en te installeren. Daarna heb ik de tutorial doorgenomen en ik was behoorlijk verbaasd over de mogelijkheden.

De oude discussie tussen RDBMS en OODB. Ik zou zeggen, lees de oude artikelen van Codd en Chen eens door en je ziet al snel de beperkingen van OODBs. Ga maar eens een rapportje maken op een OODB waarbij je nieuwe entity definitions (Codd/Chen) creeert dmv projections of joined sets. Dat is nu juist de kracht van een RDBMS: data is niet fixed binnen een entity, je kunt er meer mee.

Natuurlijk is een tutorial een mooi verkoopspraatje en vroeg ik me af of andere mensen reeds ervaringen hebben met Db4o of andere OODBMS'en. Hier op GoT zag ik Gerco al enkele malen db4o voorstellen in allerhande topics, maar daar werd verder weinig aanbod besteed aan de DB.

dat komt wellicht omdat het hele hoofdstuk 'OODB' al een tijdje geleden is afgesloten. Al tientallen jaren proberen OODB fabrikanten hun waar te slijten en het wil maar niet lukken. Het grote probleem met OODBs is dat je te fixed met je data moet omgaan: je gaat met objects om, niet met attribute instances binnen een entity. M.a.w.: zodra je een join wilt doen of set logic over een joined set gaat het wringen.

Naarmate ik ervaringen met deze DB opdoe, (ik ben nl. wegens de NHibernate historie even van scratch herbegonnen, maar dan wel formeler) kan ik gerust mijn eigen ervaringen posten.

Ik hoop dat het een hobbyprojectie is, want was het anders niet gewoon beter geweest als je het gewoon had gemaakt zoals de beschikbare tools je in staat stelden te doen?

In Friesland hebben we er een mooi gezegde voor: "As `t net kin sa`t it moat, dan moat it mar sa`t it kin".

[RobIII]

Na lang wikken en wegen (en een TR van whoami ) toch maar even tikje naar SEA

[ Voor 4% gewijzigd door RobIII op 16-06-2009 10:36 ]

[H!GHGuY]

TeeDee schreef op maandag 15 juni 2009 @ 22:38:
Even ontopic nog:
Heb zelf nog geen ervaring met 'pure' OO DBMS-en, maar op een of andere manier ben ik gehecht aan de abstractie die een LLBLgen bijvoorbeeld geeft. Neemt niet weg dat het uiteraard een interessant iets is om te bekijken/testen.

Ik heb ook even naar LLBLgen gekeken en het prijsmodel stond me niet aan
Dit is een hobby-project, die ik op het werk wil gaan deployen (enkel voor mezelf en mss geinteresseerde collega's). Gratis is 1 belangrijk punt.
Daarnaast heb ik voor Db4o gekozen omdat een reguliere DB (SQLite en andere lightweight DB's daar gelaten):
- teveel resources eet (+ extra installatie vereist)
- mij het probleem van mapping geeft, waar ik niet meteen een oplossing voor vond. OODB's sluiten hierbij beter bij mijn probleem aan, door meteen inheritance en alle andere mogeijkheden te supporteren.
- because I can (hobby-project, remember)
- ik al langer wel eens een OODB wil gaan gebruiken (tijd terug een cursus gehad over ODMG en OO binnern RDBMS)
SQLite heeft bovendien de limitering dat schema evolution nogal pijnlijk kan zijn.

Gerco schreef op maandag 15 juni 2009 @ 22:13:
Daar ben ik het helemaal mee eens. Een grote misser in db4o voor de OSS ontwikkelaar was altijd dat er voor de tooling betaald moest worden. De Object Manager is inmiddels gratis geworden (voor java dan toch), maar ik heb nadat dat gebeurd is eigenlijk niet meer met db4o gewerkt.

De tooling is nu, voor zover ik weet helemaal gratis geworden. Ook voor .NET is er tooling beschikbaar om bvb je klassen aan te passen voor de IActivator. Het hele IActivator gebeuren moet je dus strikt genomen niet zelf implementeren.

GrooV: Performance gaat mij helemaal niet aan. Ik gebruik op dit moment Outlook voor mijn taken en er staan nu, over een periode van enkele maanden +-750 taken in. Ik zou dus uitkomen op mss 1500 objecten per jaar. Om je alsnog een antwoord te voorzien: Db4o gebruikt een query optimizer en probeert zoveel mogelijk om data te doorzoeken zonder de objecten zelf te instantieren. Soms kan het echter niet anders en dan moet elk object gedeserialized worden om daarna geevalueerd te worden.

@Efbe:
Ik kan mbv C# en LINQ iets doen als:

C#:

var x = from MyObject o in ctr
           where o.X = 1;
           select new OtherClass(o.X, o.Y);

en zoveel meer. Je bent dus niet meer gebonden aan de objecten die je DB je aanbiedt.
Bovendien als je dan toch OO werkt, waarom zou je dan subsets van je objecten gaan gebruiken?

[whoami]

Bovendien als je dan toch OO werkt, waarom zou je dan subsets van je objecten gaan gebruiken?

Omdat je niet altijd geinteresseerd bent in de entities zoals deze door je domain-model gedefinieerd zijn ?
Ik heb bv entities, en ik heb ook een aantal 'projections' van die entities die ik gebruik in overzichtsschermen bv.

[EfBe]

H!GHGuY schreef op dinsdag 16 juni 2009 @ 13:07:
[...]
Ik heb ook even naar LLBLgen gekeken en het prijsmodel stond me niet aan

tja

Dit is een hobby-project, die ik op het werk wil gaan deployen (enkel voor mezelf en mss geinteresseerde collega's). Gratis is 1 belangrijk punt.
Daarnaast heb ik voor Db4o gekozen omdat een reguliere DB (SQLite en andere lightweight DB's daar gelaten):
- teveel resources eet (+ extra installatie vereist)

Teveel resources eet lijkt me echt onzin. Tenzij je oracle enterprise gaat installeren maar dat lijkt me toch niet van toepassing. De extra installatie is voor bv firebird embedded niet nodig.

Dus aangezien die andere databases al werken, waarom dan moeilijk doen?

- mij het probleem van mapping geeft, waar ik niet meteen een oplossing voor vond. OODB's sluiten hierbij beter bij mijn probleem aan, door meteen inheritance en alle andere mogeijkheden te supporteren.

Iedere goede o/r mapper support ook inheritance, en verder zoals ik al eerder zei: als je tooltje zo simpel is, is het dan niet beter gewoon te bouwen wat werkt?

SQLite heeft bovendien de limitering dat schema evolution nogal pijnlijk kan zijn.

Schema evoluties zijn altijd pijnlijk want je moet altijd migreren, dat is bij een OODB niet anders.

@Efbe:
Ik kan mbv C# en LINQ iets doen als:

C#:

var x = from MyObject o in ctr
           where o.X = 1;
           select new OtherClass(o.X, o.Y);

en zoveel meer. Je bent dus niet meer gebonden aan de objecten die je DB je aanbiedt.
Bovendien als je dan toch OO werkt, waarom zou je dan subsets van je objecten gaan gebruiken?

Waarom? Omdat het soms nodig is Je moet niet in objects denken, maar in entities. Denken in objects mbt data zorgt er veelvuldig voor dat mensen fouten maken die nergens voor nodig zijn.

Maar aangezien het een hobby projectje is, tja, hobby lekker raak zou ik zeggen daar is het hobby voor tenslotte.

[H!GHGuY]

EfBe schreef op dinsdag 16 juni 2009 @ 13:49:
Teveel resources eet lijkt me echt onzin. Tenzij je oracle enterprise gaat installeren maar dat lijkt me toch niet van toepassing. De extra installatie is voor bv firebird embedded niet nodig.

Databases zijn nou eenmaal memory hungry. Mijn laptop op het werk heeft 2GB waarvan er geregeld 1GB in gebruik is voor een VM en waar ik anders gemakkelijk een tiental applicaties tegelijk op draai. Ik heb dus elke MB RAM nodig.

Lightweight DB's zoals SQLite/firebird embedded hebben idd geen installatie nodig, maar aangezien ik niet alle CRUD handmatig wil gaan coderen heb ik meteen een O/R-mapper nodig....

Iedere goede o/r mapper support ook inheritance, en verder zoals ik al eerder zei: als je tooltje zo simpel is, is het dan niet beter gewoon te bouwen wat werkt?

... en daar kwam ik dan op het probleem wat je in mijn andere topic vindt. Het is niet 'zomaar' inheritance

Vanuit OO standpunt is het simpel. De mapping in een DB is dat denk ik echter niet. Daarenboven heb ik echt wel meer in gedachten dan een lijstje taken bijhouden

Schema evoluties zijn altijd pijnlijk want je moet altijd migreren, dat is bij een OODB niet anders.

Juist, maar SQLite bvb supporteert niet alle commando's om je schema aan te passen.
Zie maar even http://www.sqlite.org/omitted.html

[EfBe]

H!GHGuY schreef op dinsdag 16 juni 2009 @ 19:44:
[...]
Databases zijn nou eenmaal memory hungry. Mijn laptop op het werk heeft 2GB waarvan er geregeld 1GB in gebruik is voor een VM en waar ik anders gemakkelijk een tiental applicaties tegelijk op draai. Ik heb dus elke MB RAM nodig.

Zelfs met een embedded db als ms access of sqlserver ce desktop (v3.5 natuurlijk, de oudere zijn crap) is het echt niet zo memory hungry als jij doet voorkomen.

Lightweight DB's zoals SQLite/firebird embedded hebben idd geen installatie nodig, maar aangezien ik niet alle CRUD handmatig wil gaan coderen heb ik meteen een O/R-mapper nodig....

Maar die zijn ook wel gratis te verkrijgen, zoals bv nhibernate, of als je wat anders wilt bv EUSS.

[...]
... en daar kwam ik dan op het probleem wat je in mijn andere topic vindt. Het is niet 'zomaar' inheritance

Jawel hoor, daarom zei ik ook 'denken in entities'. dan is inheritance niet zo moeilijk. Zodra je in code gaat denken loopt het mank. Maar denken in code is de fout die veel mensen maken. het probleem is dat de code een projectie is van een abstract entity model op een programmeertaal. je zit dus met de projectie te werken en die wil je dan persisten. Dat wil je dan doen in tables die ook een projectie zijn van hetzelfde entity model, anders werkt het nl. niet: dan is er geen basis voor de o/r mapping en geen relatie tussen de data in je class instances en de data in een table row.

Het denken vanuit code en classes is dan dus ook niet zo handig. Ik weet dat 'prominente' figuren in de .NET wereld anders roepen, maar die snappen door de bank genomen niet veel van de materie.

En als je per se interfaces wilt mappen, gebruik je toch EUSS van Evaluant http://www.codeplex.com/euss? Ik ken de maker ervan vrij goed en ik zou euss nog eerder gebruiken dan nhibernate, maar goed wie ben ik

Juist, maar SQLite bvb supporteert niet alle commando's om je schema aan te passen.
Zie maar even http://www.sqlite.org/omitted.html

Hmm, dat is behoorlijk brak. RIGHT joins zijn op zich wel noodzakelijk bv als de o/r mapper de query wil optimizen of zodanig de query genereert dat de left join omgegooid moet worden naar een right join. De rest valt mee, je kunt tables migreren door een nieuwe te maken, data te copieren en dan de oude weg te gooien en de nieuwe te renamen. FKs kent ie toch niet .

Ik zou dan voor firebird embedded gaan, want je kunt gewoon je programma met de firebird server maken en als je gaat deployen de embedded dll meeleveren en 1 setting veranderen in de connectionstring.

[H!GHGuY]

EfBe schreef op dinsdag 16 juni 2009 @ 20:39:
Jawel hoor, daarom zei ik ook 'denken in entities'. dan is inheritance niet zo moeilijk. Zodra je in code gaat denken loopt het mank. Maar denken in code is de fout die veel mensen maken. het probleem is dat de code een projectie is van een abstract entity model op een programmeertaal. je zit dus met de projectie te werken en die wil je dan persisten. Dat wil je dan doen in tables die ook een projectie zijn van hetzelfde entity model, anders werkt het nl. niet: dan is er geen basis voor de o/r mapping en geen relatie tussen de data in je class instances en de data in een table row.

Het denken vanuit code en classes is dan dus ook niet zo handig. Ik weet dat 'prominente' figuren in de .NET wereld anders roepen, maar die snappen door de bank genomen niet veel van de materie.

En als je per se interfaces wilt mappen, gebruik je toch EUSS van Evaluant http://www.codeplex.com/euss? Ik ken de maker ervan vrij goed en ik zou euss nog eerder gebruiken dan nhibernate, maar goed wie ben ik

Met jouw kennis zou ik het apprecieren mocht je even naar het NHibernate-probleem in mijn vorige topic (zie link in TS) kijken. Het is niet zomaar interface inheritance. Dat kan NHibernate ook wel. Ikzelf werk in embedded en heb dus behalve wat school-projecten, thesis (met NHibernate) en wat kleine hulp aan projecten van kennissen weinig ervaring met DB-backed applicaties.

Ik ben op dit moment bezig een hoop usercontrols te maken die ik dan binnenkort samengooi in enkele forms zodat ik meteen wat CRUD kan gaan testen. Ik ben alleszins benieuwd.

[ Voor 5% gewijzigd door H!GHGuY op 17-06-2009 13:01 ]

[EfBe]

Volgens mij kan nhibernate niet queryen op interface, maar dat daargelaten. Ik zal eens kijken of ik tijd kan vinden.

[Daspeed]

Misschien wat off topic/overbodig dan, maar voor mensen die NHibernate (willen gaan) gebruiken --> NHibernate kan queryen op interface.

NHibernate queries may name any .NET class or interface in the from clause. The query will return instances of all persistent classes that extend that class or implement the interface.

http://nhforge.org/doc/nh...tml#queryhql-polymorphism

Verder ben ik eigenlijk ook wel benieuwd naar ervaringen van mensen met OO databases.

[H!GHGuY]

beany schreef op maandag 15 juni 2009 @ 21:36:
DB4O kan overigens ook als standalone server gedraaid worden, al heb ik dit zelf nog nooit gedaan. Het project is nog niet volwassen(in mijn optiek) maar ze zijn zeker op de goede weg!

Ik heb met die onvolwassendheid al mogen kennismaken...
Als je transparent persistence aanzet kan er een en ander misgaan bij het deleten van objecten.
Gelukkig heb ik er toch een beetje rond kunnen werken tot de volgende release komt (daar zal namelijk de fix in zitten).

Behalve dat is er voor die ref-counting wel wat te vinden:

C#:

public void IDataObject
{
   // Unlink this object from all objects that should remain
   // in the DB when this object is deleted
   void Unlink();
}

public class DataLayer
{
   IObjecteContainer ctr = ...;
   void Deleted(object o)
   {
      // All IDataObject-inheritors have cascade on delete enabled
      if (ctr is IDataObject)
         (ctr as IDataObject).Unlink();
      o.Delete();
   }
}

Resultaat is dat alle members waar niemand anders nog iets aan heeft blijven staan en mee verwijderd worden. Alle fields met pure data worden netjes mee verwijderd.

Bovendien bevat Db4o ook de mogelijkheid om references te controleren:
(van de website)

C#:

private static void OnDeleting(object sender, CancellableObjectEventArgs args)
        {
            Object obj = args.Object;
            if (obj is Pilot)
            {
                IObjectContainer container = OpenContainer();
                // search for the cars referencing the pilot object
                IQuery q = container.Query();
                q.Constrain(typeof(Car));
                q.Descend("_pilot").Constrain(obj);
                IObjectSet result = q.Execute();
                if (result.Size() > 0)
                {
                    Console.WriteLine("Object " + (Pilot)obj + " can't be Deleted as object container has references to it");
                    args.Cancel();
                }
            }
        }