You can switch that off for a long time already (so it produces null instead of a new entity). It only happens in lazy loading scenario's and the new entity is produced for backwards compatibility as the first versions had that feature.
Furthermore, if you run into this, your code relies on data it doesn't check: you request related entities from the db which aren't there, but don't check what's returned. If you'd do that, you wouldn't have a problem.
Frans, I realize that you are defending your product, so I please understand if I don't consider you entirely objective.
I wasn't talking about the rest of the products, just my own, and I don't know how I
can't be not objective about my own product. ;). You're talking about my hard work, so I'll do my best to place that into a perspective where it makes sense.
And I'm very glad that you have fixed the problem. However at the time that i used the product, it was really a sore point with me. It was so uncharacteristic of how the .NET framework works. In .NET, as well as most programming languages, if you attempt
to get the 3rd item out of a recordset, and there are only 2 records, you get an immediate error.
Yeah, well, ever tried to read the 3rd entity from an entity collection when it wasn't there? You did get the error, right? There is ONE particular situation where you didn't get a null, but an empty entity back. The reason is quite simple: an 'entity' is 'data'.
The entity object is a container for an entity or better: for its
data . So if an entity isn't there, you get an empty container. That was the reasoning behind it. After a while it turned out that there were more people who didn't understand it than people who did, or better: who found it logical, so it was a mistake.
We all make them. The thing is, you could test on it in your code and no problem at all. I added a fix for those people who wanted to test for null, instead for an entity state.
If you attempt to reference a property in a null object, you get an error. If you attempt to get a field out of an IDataReader that isn't there, you get an error. The framework NEVER instantiates something
for you automatically. Your product did.
Yes, for a logica reason (see above). And let's not keep the .NET framework as 'consistent' reference, shall we? I mean, adding a subnode to a treeview node is different than adding a subnode to an XmlNode...
But there was no way to know it was doing that, until later on when you tried to save, at which point it finally thru an exception. NOT an exception about the null object, but about a bad query (because it was
creating an insert statement with no columns if I remember.)
Of course you could test for it
[code]
CustomerEntity myCustomer = myOrder.Customer;
if(myCustomer.Fields.State!=EntityState.Fetched)
{
// not fetched, not there, act accordingly
}
[/code]
That's why I said: you used code which didn't check what was read or not. I admit that returning null would have been better. But as said, it's been fixed for a looooooong time as in: you can switch off the behavior and have a null returned. Code which did
test on it would instantly break if I changed the behavior of course, so that's why it was never changed.
We also support a completely different paradigm, 'Adapter', which doesn't have this (as it doesn't have lazy loading, as it uses a different 'distribution of concerns' implementation)
There is a saying in Taoism that I think applies to many aspects of life, including programming: "Meet problems early." Your product, by instantiating the null object without telling the developer, put the
problem off until much later in the lifecycle (potentially several postbacks or even several pages later in an ASP.NET app) and therefore much more difficult to deal with. I do agree that you are going to have to check sometimes for null or empty data. Every
object developer and every O/R Mapper has to deal with the problem of nulls. However, the fact is that all of us will make mistakes and try to reference things that aren't there whether they are records, collection items or individual objects. Who among us
has not gotten the ubiquitous "Object reference not set to an instance of an object" error? :) All of us sometimes forget to check for nulls on an object or chunk of data. The way your product dealt with nulls actually obfuscated mistakes like these and made
a relatively simple exception (null reference) into something much more difficult to track down later on. Worse, some of these errors made it into production whereas if your product had immediately given the "object reference" exception, much head scratching
would have been avoided.
Sorry, but you're very mistaken. Dealing with NULL values is something completely different than giving a new entity
object when no entity data is there. LLBLGen Pro is one of the very few O/R mappers which actually actively dereferences related objects when you set an FK field to null or a different value, and that's disconnected, e.g. high up in your asp.net
stack for example:
myOrder.CustomerID = "Foo";
will set myOrder.Customer to null, reset lazy loading for that field and if you then do:
CustomerEntity c = myOrder.Customer;
it will be fetched again, that is, if you use SelfServicing of course. Adapter doesn't use lazy loading and also doesn't have the problem you described above.
Also, what I find a little annoying is that you now vent here about 1 single feature, which result was testable easily, and you should have done that. It also doesn't have anything to do with NULL value handling whatsoever. Neither have you been looking
at 'Adapter', the other paradigm we support apparently. You might have used LLBLGen Pro a long time ago, but a lot has changed since then. Presenting it as if it still HAS a 'bug' is IMHO unfair, every bug is addressed a.s.a.p. but on a way that's workable
for all our customers.
I don't know if you remember, but you and I had emailed each other back and forth quite a bit about this issue. At the time, my perception was that you didn't seem very concerned about the issue. I'm pleased
that you have made it a priority and understand that you have to have leave the "lazy instatiating" as an option for backwards compatiibility.
Well, it wasn't an issue which you couldn't prevent yourself, but what was a problem for me was that I couldn't change the behavior all of a sudden as that would break a lot of applications of others. I made a switch which could be used by users to switch off
this behavior, which IMHO is the only real way to deal with things like this.
FransBouma
Having mappings in an xml file isn't very 'version' friendly either. If you have 10 revisions of the mapping file, and you have a large system, chances are you're in trouble too if you want to copy/paste mappings over, as that's a lot of xml to wade through.
I completely disagree. When using your product, we had a contractor working offsite and out of state. That contractor was often disconnected from our VPN and therefore from our source control (VSS). Occasionally, she would have to make changes to the data
structure and therefore the LLBLGen project file and generated code. When she checked back in, there were times that I already had made change to the data structure and mappings as well. Merging the changes was a chore that ranged from painful to nearly
impossible. The project file/mapping was in a binary format, so no merge/diff tool could sync up the differences. We couldn't even "eyeball it" and copy individual changes from one person's version of the file to the other, because of the proprietary format.
So each time we got out of sync, one of us would have to get on the phone with the other, go in to the GUI and manually add the changes thru point and click and hope we got them exactly right.
And then you blame the format of the data? Oh my...
No offence, but if you distribute work over a couple of people, you have to be sure that work is possible to be done in parallel. If you both have to change the same .jpg files or the same database tables, it's not a good system to let 2 people do that asynchronously.
I've customers where they work in teams with 100 developers or even more, do you really think they all are allowed to change the project file? No of course not. That's restricted to a few people who make the changes so they're made at the right time at the
right place.
THe same is true for your live database schema. Ever tried to 'merge' changes with a difftool ? That's pretty hard too. Though that's not a bad thing, you can easily schedule changes to be made, let one person do it, and let that person distribute the changed
project file to the rest of the team.
I agree that 10 versions of the a large mapping could be problematic, but we only had 2 versions we were trying mess with. Are you really going to suggest to me that XML, which is human readable and can be synched using a merge tool, isn't going to be far,
far easier to fix problems like this than your proprietary binary format?
Well, if you have the db schema information IN the mapping file (most xml mapping file using o/r mappers simply STATE that those are the mappings, the actual schema info isn't there, in an .lgp file it is, so you can work on it disconnected from the db,
safely), the mapping file will be big if you reach 100 entities and beyond imaginable when you reach 1000. I first had xml export for it but it was too verbose and way too slow to read in. Mind you: we're talking about a project file which allows you
to make SAFE mappings, as the catalog(s) schemas are available.
If you think you can merge XML changes manually 'easily', go ahead. THough with a large project, that's undoable, I can tell you. The better way to deal with this is to simply schedule the work better, so there's always just 1 person making changes to a file,
as there's also just 1 person making changes to the project's database schema, or were you two also changing that on multiple places which then had to be merged together later on? That's not workable, it takes too much time and it can be done easier by scheduling
work properly. It's also error prone, merging xml files by hand if in both files changes have been made, because... have you already made the proper db schema changes?
And if this is a system which is already in production, have you made the proper data migration scripts already? Because merging in a mapping definition from another person, can only be done safely if you know the schemas are the same as well.
FransBouma
Well, you often need a decorator more than an inherited type. A lot of inheritance trees aren't really hierarchies of very different types, but just behavior changes, something which you can do with all mappers today. Real type inheritance as in: employee -
manager - boardmember and boardmember then has a relation with companycar, is not that common, as it also shows problems when you want to semantically promote an entity (i.e. its data) to another type, for example make a manager a boardmember in the example
above. You then are better of with a decorator pattern implementation than with an inheritance tree.
I agree that real inheritance is rare. Inheritance is NOT the silver bullet of code reuse that some beginners to the OOP paradigm seem to think it is. However, when a true inheritance hierarchy presents itself, using a decorator pattern or delegation or something
tends to be rather ugly in my experience. A bit like trying to squeeze a square peg into a round hole. Its a matter of using the the right tool for the right job: use inheritance when you see an "is a" or "is a type of" relationship and composition or aggregation
when there is a "has a" relationship. The latter is more common; the former is still very useful at times.
Sure, but you forget that inheritance in classes is something else than inheritance in entity types. In a db, you can have semantically multiple inheritance and also change a type of an entity by changing it's data, it's all semantic interpretation anyway (as
the real model describes supertype/subtypes but it needs a conversion to a database schema DLL to be useful). (not all pk-pk 1:1 relations are inheritance relations).
This means that you have to jump through hoops to move an entity from one type to another. When you really need inheritance it's nice it's there. Though it's harder than you think to come up with a hierarchy which really needs entity supertype/subtype constructs,
thus not inheritance to make polymorphism possible. Furthermore, having inheritance in the database is nice, though it has performance implications in some areas. Especially with large(r) tables.
-XML mapping/configuration file
FransBouma
You will be bitten by this. A serialized object model is very easy to use for example: you can write a few lines of code to load your .lgp file into memory and manipulate it with simple code :)
Possibly. But I doubt I will be bitten as bad as I was with your .lgp file. I wasn't aware that you could maniuplate the project file as an object, or maybe that wasn't in the feature set at the time that we used it.
No, it's been there all the time. :) We ship an SDK with the complete object model documented. You as a customer can still download it and for example use our Template Studio (ala codesmith studio) to write little templates against it, and if you look into
the object model, you'll see that you can load a project into memory in 1 line of code, and then every element is there, usable as a normal object graph, not through XML voodoo. :)
Nevertheless, you confuse mapping information needed to make mappings possible at design time and mapping information needed to make mappings possible at runtime. LLBLGen Pro uses code generation (which in fact 'pre-calculate' mapping interpretation for you
in code) instead of a mapping file, which allows objects to travel freely through your application, distributed or not, without the necessity of a mapping file at every spot it is used.
That would have been easier for us to synch up differences, although I doubt as easy as copying and pasting a few lines of XML. And couldn't your project file's object model could just as easily be serialzed down to xml, that way you could alter it programatically
the way you mentioned by manipulating the object model, OR alter it using notepad the way i mentioned? Best of both worlds?
You really don't know the amount of information available/required in the project file ;) If it was easy to pack all that info in a tiny little xml file, even in large projects, no problem. Though its not. Schema information of databases alone is very verbose.
Let me also say that lots of O/R Mappers use and XML configuration file or XML serialization of the "mapping objects" the way I describe. NHibernate, WORM and IdeaBlade are just a few. There must be something
to that whole "easy to read, easy to parse."
Yeah, well, what you're refer to is the mapping file which is used at runtime. LLBLGen Pro doesn't use a slow XML file at runtime, but code generation at design time. And, do these tools have a gui designer which allow you to keep your schemas of multiple
catalogs in your project file so you can work on it disconnected from your db? No, or when they do, you will be very surprised how big the data is when you serialize a full schema to XML. No-one with a right mind would do that, OR it would be a tool targeted
towards small(er) applications. In enterprise development, having to deal with 10-20MB xml files is not what you want, I can tell you that. So, stripping out the info to allow you to make mappings in a designer, leaves smaller xml files, but then again, you
don't have the info to make proper mappings in a designer, or better: let the designer do the work for you. Or are you suggesting that making mappings for 300 entities in an xml file BY HAND isbeing 'productive' ?
Frans, I am sorry if this post and my original post seem a little harsh. The fact was, we were your customers and our experience with your product was not very positive. I emailed you for help and I give you credit for being very prompt in getting back to
us. However, you didn't seem to interested in what I and other developers saw as some major, logical flaws in your product.
I count 1 feature which you could work around and a bad way to schedule your own work. Where are the 'major' flaws? I already admitted that it wasn't a great decision to return a new entity, but what can I do after that? Not much, just add a switch, after all,
this is professional software, and that shouldn't break your applications when you apply a patch.
If you have noticed other 'major' flaws which were there in 2003, early 2004, tell me, though be aware that the version you've used is revisited a couple of times already, for example a complete different paradigm has been added.
That being said, there were LOTS of things i really liked about LLBLGen: strongly typed object queries, collection generation, the inheritance hierarchy it created for regens, the GUI was great, support for relationships that were NOT in the database as contraints
or RI, and so on. And it looks like you are getting some of the major blemishes the product cleaned up.
Yes, of course I cleaned up the issues, I always do :). But some issues are design flaws as in 'it would have been better if...' and can only be countered by adding logic to switch off those features etc. as with a lot of customers with large projects, you
can't just change something so fundamental as the issue with the returned entity on a lazy loading event, as that would break their applications.
I'm sorry your experience was not as you'd expected. I hope you understand that my options in the particular situation you're talking about weren't great (rock, hard place). Also I hope you'll understand that the difficulties you had with development in
a distributed environment takes proper pre-cautions to make things run smoothly. You can't solve that by using XML files, you can only solve that by proper scheduling of work, because otherwise you're STILL fixing the results of inproper scheduled work, by
hand, which can /will be cumbersome, time consuming AND above all.... error prone.
It's up to you, you're still a licensee, you can still take a look at the current version :)
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
As this discussion is getting very long, let me address some of your points briefly, rather than quoting the entire thread.
1) Of course we could test for the null object. We eventually found a work around for the issue, by specifically checking areas where the returned object had the potential of being null. That's not the point. The point is that the product wasn't very "developer
friendly" if you forgot to do this, as we are all likely to do at times. Debugging this, as I said before, was a nightmare. And as you pointed out, the product wasn't even being consistent with itself, much less the .NET framework. You did get an error
if you attempted orders[3].ProductName when you only had 2 orders in the entity collection, but you DIDN'T get an error when you said Order.Customer.FirstName if there wasn't an error there. I understand your thought process about objects being merely containers
for data, although I think some people would disagree. Some people think along the lines of: "1 record equals 1 object instance. Missing record equals null object reference." This has always been my position, and I don't think that line of thinking is
uncommon, but it is certainly debatable. IdeaBlade also instantiates an object if you try to reference something where the data isn't there, but that object is not saveable or changeable and is marked as a "Null".
2) I DO think you should strive to be consistent with how the .NET framework works. It drives me CRAZY when i get a UI product for example, that has a "disabled" or "Invisible" property rather than the traditional "enable" and "visible" properties that every
other intrinsic web control has.
3) One can argue that our development process was the problem until you are blue in the face. To some extent, I agree. I prefer to either have everyone work off the same database and/or have only one person who is allowed to make database changes. I prefer to
not allow multiple checkouts of files. However with the offsite developer, that wasn't always possible--and out of my control. It was an exception rather than the rule. Most of the time, we would not allow this parallel develpment. When it did happen,
at least with the database, we could script our changes and synch up our changes by running them. With LLBLGen project files, we ran into a lot of trouble if we were both working on the project file at the same time. Also, keep in mind that many source control
packages (other than VSS) allow parallel development and simulataneous checkout of files, and then have the developer perform a "diff". Many shops use this paradigm, and allow multiple developers to work in parallel. Most of the mapping solutions like WORM
or NHibernate have pretty simple xml, because they don't do all that code generation for you so the mapping is easier to synch up. That's probably comparing apples to oranges since your product does the "mapping' and ALSO generates the code, therefore you
have to store a lot more metadata. However, IdeaBlade does the same thing that LLBLGen does, and its XML file is very easy to edit, should 2 developers get out of synch. There IS a lot of XML if you lots of tables and fields, but its not complex. For the
record, I don't consider XML "voodoo": its easy to read, easy to parse and doesn't require me to compile anything to make a change. I can open IdeaBlade's xml, make a change, open up the UI and see my changes in the UI. Your SDK does sound interesting though,
and I'll have to take a look at it when I get some time.
5) We did have some other major problems with LLBLGen including some stuff that required hot fixes that you provided to us. This was fine, but the hot fixes either did not work or caused our project files between myself and the offsite developer to become
incompatible, even though we used the same hot fixes. It wasn't really just the one issue with nulls, although obviosly that was the one that sticks out in my mind the most. Do you really want to address the rest of our issues here?
As this discussion is getting very long, let me address some of your points briefly, rather than quoting the entire thread.
1) Of course we could test for the null object. We eventually found a work around for the issue, by specifically checking areas where the returned object had the potential of being null. That's not the point. The point is that the product wasn't very "developer
friendly" if you forgot to do this, as we are all likely to do at times. Debugging this, as I said before, was a nightmare. And as you pointed out, the product wasn't even being consistent with itself, much less the .NET framework.
Where did I point that out? It IS consistent with itself, I just added some things I found logical. Why should I stick to the .NET framework 'consistency' if the .NET framework isn't consistent either?
I understand your thought process about objects being merely containers for data, although I think some people would disagree. Some people think along the lines of: "1 record equals 1 object instance. Missing
record equals null object reference." This has always been my position, and I don't think that line of thinking is uncommon, but it is certainly debatable. IdeaBlade also instantiates an object if you try to reference something where the data isn't there,
but that object is not saveable or changeable and is marked as a "Null".
Of course things are debatable, and I agree with you that returning 'null' would have been better, as I've said a dozen times already. I also explained why that wasn't an option, and I hope that's all clear now. You also forget to mention you talk about a version
which is more than a year old (before feb 2004)
2) I DO think you should strive to be consistent with how the .NET framework works. It drives me CRAZY when i get a UI product for example, that has a "disabled" or "Invisible" property rather than the traditional "enable" and "visible" properties that every
other intrinsic web control has.
True, but if I think something is more workable I use that. This null issue was a mistake from my part, but every products has mistakes in its design.
3) One can argue that our development process was the problem until you are blue in the face. To some extent, I agree. I prefer to either have everyone work off the same database and/or have only one person who is allowed to make database changes. I prefer to
not allow multiple checkouts of files. However with the offsite developer, that wasn't always possible--and out of my control. It was an exception rather than the rule. Most of the time, we would not allow this parallel develpment. When it did happen,
at least with the database, we could script our changes and synch up our changes by running them. With LLBLGen project files, we ran into a lot of trouble if we were both working on the project file at the same time. Also, keep in mind that many source control
packages (other than VSS) allow parallel development and simulataneous checkout of files, and then have the developer perform a "diff". Many shops use this paradigm, and allow multiple developers to work in parallel.
You really think you can do a diff on a large XML file which contains all the mapping info for a 300 entity project and work with that? Dream on :). Sure, that diff is made, but then you have to merge it by hand, which is tedious and error prone.
Most of the mapping solutions like WORM or NHibernate have pretty simple xml, because they don't do all that code generation for you so the mapping is easier to synch up. That's probably comparing apples to oranges since your product does the "mapping' and
ALSO generates the code, therefore you have to store a lot more metadata. However, IdeaBlade does the same thing that LLBLGen does, and its XML file is very easy to edit, should 2 developers get out of synch.
I don't know IdeaBlade, but I doubt they use the same amount of data to work with. LLBLGen Pro doesn't compromise on anything nor does it 'limit' you on database options like 'always use 1 field pk's' or other sillyness. That takes information and that eats
up size. I did look into this a couple of times but it was impossible to make it useful. Take note that binary serialized data of a large project already takes some time to load, let along XML data of that magnitude... It's not fast enough.
There IS a lot of XML if you lots of tables and fields, but its not complex. For the record, I don't consider XML "voodoo": its easy to read, easy to parse and doesn't require me to compile anything to make a change. I can open IdeaBlade's xml, make a change,
open up the UI and see my changes in the UI. Your SDK does sound interesting though, and I'll have to take a look at it when I get some time.
No, I meant the code to get everything out of the XML dom document :).
5) We did have some other major problems with LLBLGen including some stuff that required hot fixes that you provided to us. This was fine, but the hot fixes either did not work or caused our project files between myself and the offsite developer to become
incompatible, even though we used the same hot fixes. It wasn't really just the one issue with nulls, although obviosly that was the one that sticks out in my mind the most. Do you really want to address the rest of our issues here?
No, that doesn't seem very useful for this forum. What I can't believe is that you now come to me that fixes for issues 'didn't work'. It's the first time I hear this kind of info, and IMHO if something which is supposed to be fixed isn't fixed for you, come
to me and I'll check it out. Also the issue with your off-shore developer. You're not alone in that situation, so perhaps you could have learned from fellow llblgen pro users how to solve this, or I could have adviced you sooner.
Again, I'm sorry your experience isn't as nice as you'd expected, though much has changed since you've used it. But if you think XML files are the way to go, go ahead, I think you'll learn they have major drawbacks too. :)
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
Hi Guys. Very interesting thread on O/R Mappers here. I was wondering if anyone of you will be interested in testing out my RAD Framework that comes with O/R Mapping. It basically comes with a core library that handles all the basic CRUD activities and also
comes with its own Code Generator as well.
Where did I point that out? It IS consistent with itself, I just added some things I found logical.
You mentioned this inconsistency earlier -- how in this ONE particular situation, you were doing something different than how you normally do it in LLBLGen:
FransBouma
Yeah, well, ever tried to read the 3rd entity from an entity collection when it wasn't there? You did get the error, right? There is ONE particular situation where you didn't get a null, but an empty entity back.
However, in most other respects, your API is pretty consistent.
FransBouma
Why should I stick to the .NET framework 'consistency' if the .NET framework isn't consistent either?
Actually, I find the .NET framework very consistent, especially compared to other languages such as VB6 and even Java. Consistency is really important, as it lessens the learning curve in any API and improves developer productivity.
FransBouma
Of course things are debatable, and I agree with you that returning 'null' would have been better, as I've said a dozen times already. I also explained why that wasn't an option, and I hope that's all clear now. You also forget to mention you talk about a version
which is more than a year old (before feb 2004)
Sorry, I thought we were still discussing my particular experience with you and your product, on that particular version. I was merely responding to your posts about what we could do or not do at that particular time. You seemed frustrated that we just didn't
just obsessively check for "empty" objects all over the place (both back when I had originally emailed you about the issue, and now on the forums.) I was also explaining why I think it was a more serious issue than you gave credit to at the time.
In any case, I"m glad its since been fixed.
FransBouma
You really think you can do a diff on a large XML file which contains all the mapping info for a 300 entity project and work with that? Dream on :). Sure, that diff is made, but then you have to merge it by hand, which is tedious and error prone.
Nice sarcasm.
Of course I don't think something that big is going to be easy. But I was only trying to alter a FEW COLUMNS, on a relatively small schema, using your product. I think that SHOULD be easy. I think a 300 entity project would require a lot of work to synch
up if two versions were out of wack, regardless of whether you're using XML or an object model.
On the other hand, I have done diffs on pretty large HTML/ASPX files, which isn't that much different from XML. As long as the thing generating the XML doens't change the order of the data each time (like VS.NET project files do) you shoudl be ok with a diff
tool. Definitely not a walk in the park, but doable.
FransBouma
I don't know IdeaBlade, but I doubt they use the same amount of data to work with. LLBLGen Pro doesn't compromise on anything nor does it 'limit' you on database options like 'always use 1 field pk's' or other sillyness. That takes information and that eats
up size. I did look into this a couple of times but it was impossible to make it useful. Take note that binary serialized data of a large project already takes some time to load, let along XML data of that magnitude... It's not fast enough.
IdeaBlade definitely has its own quirks. I haven't noticed a performance hit when loading a project, but I haven't opened a really huge project yet. I'll have to defer to someone who's used the "XML based" mappers more than I have, as LLBLGen and CSLA (which
is not a mapper) are the two products I've used the most. Has anyone had performance issues opening the IDE for IdeaBlade, Paul Wilson's WORM or NHibernate? I'm not sure the last one has an IDE, but I could be wrong.
FransBouma
There IS a lot of XML if you lots of tables and fields, but its not complex. For the record, I don't consider XML "voodoo": its easy to read, easy to parse and doesn't require me to compile anything to make a change. I can open IdeaBlade's xml, make a change,
open up the UI and see my changes in the UI. Your SDK does sound interesting though, and I'll have to take a look at it when I get some time.
No, I meant the code to get everything out of the XML dom document :).
Ah, well thats kind of your problem isn't it? I'm not saying outputting the project file would be easier for YOU, just easier for your customers to "eyeball." Kind of like we do with VS.NET solution and project files when something isn't easily fixable in
the IDE. I can do a Find/Replace or Copy/Paste in a vs.net file pretty easily, because its xml, but I admit your files might be too big for that.
Also, I was thinking you would use the XML (Soap?) serialziation classes in .NET, which would load and save everything for you from the objects to disk as long as you marked those classes serializable. I wasn't thinking you would walk the document tree using
the DOM. But it was just a suggestion. It may not be viable.
FransBouma
5) We did have some other major problems with LLBLGen including some stuff that required hot fixes that you provided to us. This was fine, but the hot fixes either did not work or caused our project files between myself and the offsite developer to become
incompatible, even though we used the same hot fixes. It wasn't really just the one issue with nulls, although obviosly that was the one that sticks out in my mind the most. Do you really want to address the rest of our issues here?
No, that doesn't seem very useful for this forum. What I can't believe is that you now come to me that fixes for issues 'didn't work'. It's the first time I hear this kind of info, and IMHO if something which is supposed to be fixed isn't fixed for you, come
to me and I'll check it out. Also the issue with your off-shore developer. You're not alone in that situation, so perhaps you could have learned from fellow llblgen pro users how to solve this, or I could have adviced you sooner.
Again, I'm sorry your experience isn't as nice as you'd expected, though much has changed since you've used it. But if you think XML files are the way to go, go ahead, I think you'll learn they have major drawbacks too. :)
No we actually did ask for some hot fixes, downloaded them based upon your suggestion and could never get them quite right. Some of the issues we emailed you about, and some of it we did not. We ran out of time and just had to work around the issues. Also,
you're outside the U.S. so I think the time difference made communcation more difficult. To be honest, we kind of gave up on you a bit when you didn't take the "NULL object" issue more seriously when I had emailed you about it. Your response was something
along the lines of "read the documentation" and it didn't sound like you were ever going to fix it. So I gave up emailing you issues, because this kind of left a bad taste in my mouth. That was probably wrong of me, since you were only minimizing the importance
of that one particular issue (which as you mentioned, has since been fixed), not telling me to not communicate with you at all.
There were some issues we simply did not report, because we couldn't wait for a response. I find this VERY, VERY common in software development. Users using your product will not report many bugs, simply because of the perceived time it would take to explain
and wait for a solution, especially if they feel they've been talked down to. More commonly, they will work around the issues, or quit using the product, especially if those users happen to be developers.
Again, Frans I don't mean to make you defensive. I'm just telling you (and others) what my experience with the product and support was at that time. I think an O/R mapping product is a huge undertaking that I personally don't think I could manage alone.
I give you credit for having solved a lot of the mapping problems very elegantly, even in that older version. I didn't start this thread to bash your product, but was telling people what I thought were major problems when I used it so they could give me possible
alternatives.
I think I'll reply on a snippet of your posting, as I've already said what I had to say [:)]
fregas
FransBouma
Of course things are debatable, and I agree with you that returning 'null' would have been better, as I've said a dozen times already. I also explained why that wasn't an option, and I hope that's all clear now. You also forget to mention you talk about a version
which is more than a year old (before feb 2004)
Sorry, I thought we were still discussing my particular experience with you and your product, on that particular version. I was merely responding to your posts about what we could do or not do at that particular time. You seemed frustrated that we just didn't
just obsessively check for "empty" objects all over the place (both back when I had originally emailed you about the issue, and now on the forums.) I was also explaining why I think it was a more serious issue than you gave credit to at the time.
True. Although there's not a lot of difference between:
[code]CustomerEntity c = myOrder.Customer;
if(c.Fields.State!=EntityState.Fetched)
{
// doesn't exist
}
[/code]
and
[code]
CustomerEntity c = myOrder.Customer;
if(c==null)
{
// doesn't exist
}
[/code]
You always have to check, no matter what. If you don't check c if it's null, you'll run into other problems. That's why I didn't make it a big deal as well, checks were necessary. Though let's close this now, it's water under the bridge and we've said what
we had to say about this[;)]
FransBouma
Again, I'm sorry your experience isn't as nice as you'd expected, though much has changed since you've used it. But if you think XML files are the way to go, go ahead, I think you'll learn they have major drawbacks too. :)
No we actually did ask for some hot fixes, downloaded them based upon your suggestion and could never get them quite right. Some of the issues we emailed you about, and some of it we did not. We ran out of time and just had to work around the issues. Also,
you're outside the U.S. so I think the time difference made communcation more difficult.
Could be, but I can't remember a day where we replied after 24 hours to a customer's support call. A time difference always is a problem, but not as big as you make it out to be. You mention here, again, that you
never could get the hotfixes or upgrades right. I'm sorry, but if I download a fix for a 3rd party product I use and the fix doesn't work, I mail the vendor, till it works OK. I think that's normal.
To be honest, we kind of gave up on you a bit when you didn't take the "NULL object" issue more seriously when I had emailed you about it. Your response was something along the lines of "read the documentation" and it didn't sound like you were ever going
to fix it. So I gave up emailing you issues, because this kind of left a bad taste in my mouth. That was probably wrong of me, since you were only minimizing the importance of that one particular issue (which as you mentioned, has since been fixed), not
telling me to not communicate with you at all.
I'm sorry if you felt been threated rudely, as that was nor is ever my intention. The thing is, if that happens again, just say so. Not communicating with a vendor about issues is of course not good.
There were some issues we simply did not report, because we couldn't wait for a response. I find this VERY, VERY common in software development. Users using your product will not report many bugs, simply because
of the perceived time it would take to explain and wait for a solution, especially if they feel they've been talked down to. More commonly, they will work around the issues, or quit using the product, especially if those users happen to be developers.
You think? If I don't report a bug to a 3rd party vendor, I then also give up the right to complain about it. No offence but it was you who brought up not only an old issue in an old version but also did you say there were other major issues. I won't deny we
had our share of major bugs in the product, as every software product has bugs and which get fixed and everyone moves on. The thing is that if you run into an issue, and you don't report it, for whatever reason, IMHO you then also give up the right to complain
about them. Just report them, even if you can't wait for a fix.
Again, Frans I don't mean to make you defensive. I'm just telling you (and others) what my experience with the product and support was at that time. I think an O/R mapping product is a huge undertaking that
I personally don't think I could manage alone. I give you credit for having solved a lot of the mapping problems very elegantly, even in that older version. I didn't start this thread to bash your product, but was telling people what I thought were major
problems when I used it so they could give me possible alternatives.
But I then wonder: what was your intention in doing so? You post about a flaw in an old version, clearly about frustration and I understand that completely. Then later on mention 'major other issues' which are not always reported to us, plus you again say you
couldn't work with the fixes we supplied. It's your right to vent about whatever you like of course, that's not why I write these postings here. What I want to achieve is that your bad customer experience is turned into a better customer experience, by explaining
my reasons and also by giving hints how to improve future communication.
Because no matter which vendor's product you'll pick for your future project(s), if you don't communicate what's on your mind, it won't work out. [:)]
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
Just a couple of quick responses Frans. I agree that we shouldn't turn this into an all out Flame war. :)
FransBouma
You think? If I don't report a bug to a 3rd party vendor, I then also give up the right to complain about it. No offence but it was you who brought up not only an old issue in an old version but also did you say there were other major issues. I won't deny we
had our share of major bugs in the product, as every software product has bugs and which get fixed and everyone moves on. The thing is that if you run into an issue, and you don't report it, for whatever reason, IMHO you then also give up the right to complain
about them. Just report them, even if you can't wait for a fix.
I disagree. As I mentioned earlier, many, many bugs go unreported and the users just gripe to each other about the software, even when the software isn't made for other developers.
Its like going to a restaraunt: You order something, the food was mediocre and the service was bad. Now, that customer my or may not tell the owner or the waiter. They might throw a big scene, or they may be too shy, too non-confrontational or just too lazy
to say anything. However, chances are they will tell their friends and aquaintences (and anyone else who will listen) not to eat there, and it is their right to do so.
It is up to the owner to be proactive and actually GO LOOKING for unhappy customers, figure out what their problems are and resolve them, before they leave the restaraunt. Its even more so in the software industry.
FransBouma
But I then wonder: what was your intention in doing so? You post about a flaw in an old version, clearly about frustration and I understand that completely. Then later on mention 'major other issues' which are not always reported to us, plus you again say you
couldn't work with the fixes we supplied. It's your right to vent about whatever you like of course, that's not why I write these postings here. What I want to achieve is that your bad customer experience is turned into a better customer experience, by explaining
my reasons and also by giving hints how to improve future communication.
Because no matter which vendor's product you'll pick for your future project(s), if you don't communicate what's on your mind, it won't work out. [:)]
Initially, I mentioned these old flaws simply to avoid any other products that had similar flaws. My assumption is that these are issues that all ORM products have to contend with, certainly not just yours.
Excuse my ignorance, but what is the difference between objects and entities?
The way I usually view it (for better or worse) is:
- An object describes a concept (usually a real world concept) and contains both the data AND behaviors associated with the object. This allows consumers of the object to only worry about the object's interface (public methods) and not the object's underlying
data structure or how it is implemented.
- An entity represents the data used to describe a concept, but NOT the behavior of the concept. The behaviors of the concept are contained in other classes that are outside the scope of the entity.
This may seem like a small semantic difference but it is an important point that ultimately can lead to very differen designs and implementations. I fall into the "object" category probably because that is the way I learned OO and software programming in general.
I would say many people who prefer the "entity" approach have learned software from a more structured (or functional) point of view than an OO point of view. There's no absolute way which is best, but I do believe there are some powerful advantages to the
OO view of encapsulation and abstraction.
Also, does anyone know how to do client-side sorting of lists with Wilson ORM? Seems to be eluding me ...
I don't know the Wilson O/R Mapper and have never used it. However, the ORM is not a GUI tool to the best of my knowledge. Anything client side is usually involved with the GUI and requires some sort of scripting language (javascript, vbscript, dhtml, etc).
I would think that any client side sorting needs to be done by the control that you are using to display the lists rather than the list objects themselves...
does anyone know how to do client-side sorting of lists with Wilson ORM?
nite--
I do not know how to do it on the client-side.
However on the server-side, as you probably have noticed, if one uses object-query language then one can sort at-will.
Alternately, it is possible to use the good old GetDataSet strategy, convert to a DataView, and then use the DataView to sort. This is not a bad solution (IMHO) for read-only views of the data.
FransBouma
Participant
1509 Points
312 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 24, 2005 08:59 AM|LINK
I wasn't talking about the rest of the products, just my own, and I don't know how I can't be not objective about my own product. ;). You're talking about my hard work, so I'll do my best to place that into a perspective where it makes sense.
Yeah, well, ever tried to read the 3rd entity from an entity collection when it wasn't there? You did get the error, right? There is ONE particular situation where you didn't get a null, but an empty entity back. The reason is quite simple: an 'entity' is 'data'. The entity object is a container for an entity or better: for its data . So if an entity isn't there, you get an empty container. That was the reasoning behind it. After a while it turned out that there were more people who didn't understand it than people who did, or better: who found it logical, so it was a mistake. We all make them. The thing is, you could test on it in your code and no problem at all. I added a fix for those people who wanted to test for null, instead for an entity state.
Yes, for a logica reason (see above). And let's not keep the .NET framework as 'consistent' reference, shall we? I mean, adding a subnode to a treeview node is different than adding a subnode to an XmlNode...
Of course you could test for it
[code]
CustomerEntity myCustomer = myOrder.Customer;
if(myCustomer.Fields.State!=EntityState.Fetched)
{
// not fetched, not there, act accordingly
}
[/code]
That's why I said: you used code which didn't check what was read or not. I admit that returning null would have been better. But as said, it's been fixed for a looooooong time as in: you can switch off the behavior and have a null returned. Code which did test on it would instantly break if I changed the behavior of course, so that's why it was never changed.
We also support a completely different paradigm, 'Adapter', which doesn't have this (as it doesn't have lazy loading, as it uses a different 'distribution of concerns' implementation)
Sorry, but you're very mistaken. Dealing with NULL values is something completely different than giving a new entity object when no entity data is there. LLBLGen Pro is one of the very few O/R mappers which actually actively dereferences related objects when you set an FK field to null or a different value, and that's disconnected, e.g. high up in your asp.net stack for example:
myOrder.CustomerID = "Foo";
will set myOrder.Customer to null, reset lazy loading for that field and if you then do:
CustomerEntity c = myOrder.Customer;
it will be fetched again, that is, if you use SelfServicing of course. Adapter doesn't use lazy loading and also doesn't have the problem you described above.
Also, what I find a little annoying is that you now vent here about 1 single feature, which result was testable easily, and you should have done that. It also doesn't have anything to do with NULL value handling whatsoever. Neither have you been looking at 'Adapter', the other paradigm we support apparently. You might have used LLBLGen Pro a long time ago, but a lot has changed since then. Presenting it as if it still HAS a 'bug' is IMHO unfair, every bug is addressed a.s.a.p. but on a way that's workable for all our customers.
Well, it wasn't an issue which you couldn't prevent yourself, but what was a problem for me was that I couldn't change the behavior all of a sudden as that would break a lot of applications of others. I made a switch which could be used by users to switch off this behavior, which IMHO is the only real way to deal with things like this.
And then you blame the format of the data? Oh my...
No offence, but if you distribute work over a couple of people, you have to be sure that work is possible to be done in parallel. If you both have to change the same .jpg files or the same database tables, it's not a good system to let 2 people do that asynchronously. I've customers where they work in teams with 100 developers or even more, do you really think they all are allowed to change the project file? No of course not. That's restricted to a few people who make the changes so they're made at the right time at the right place.
THe same is true for your live database schema. Ever tried to 'merge' changes with a difftool ? That's pretty hard too. Though that's not a bad thing, you can easily schedule changes to be made, let one person do it, and let that person distribute the changed project file to the rest of the team.
Well, if you have the db schema information IN the mapping file (most xml mapping file using o/r mappers simply STATE that those are the mappings, the actual schema info isn't there, in an .lgp file it is, so you can work on it disconnected from the db, safely), the mapping file will be big if you reach 100 entities and beyond imaginable when you reach 1000. I first had xml export for it but it was too verbose and way too slow to read in. Mind you: we're talking about a project file which allows you to make SAFE mappings, as the catalog(s) schemas are available.
If you think you can merge XML changes manually 'easily', go ahead. THough with a large project, that's undoable, I can tell you. The better way to deal with this is to simply schedule the work better, so there's always just 1 person making changes to a file, as there's also just 1 person making changes to the project's database schema, or were you two also changing that on multiple places which then had to be merged together later on? That's not workable, it takes too much time and it can be done easier by scheduling work properly. It's also error prone, merging xml files by hand if in both files changes have been made, because... have you already made the proper db schema changes?
And if this is a system which is already in production, have you made the proper data migration scripts already? Because merging in a mapping definition from another person, can only be done safely if you know the schemas are the same as well.
Sure, but you forget that inheritance in classes is something else than inheritance in entity types. In a db, you can have semantically multiple inheritance and also change a type of an entity by changing it's data, it's all semantic interpretation anyway (as the real model describes supertype/subtypes but it needs a conversion to a database schema DLL to be useful). (not all pk-pk 1:1 relations are inheritance relations).
This means that you have to jump through hoops to move an entity from one type to another. When you really need inheritance it's nice it's there. Though it's harder than you think to come up with a hierarchy which really needs entity supertype/subtype constructs, thus not inheritance to make polymorphism possible. Furthermore, having inheritance in the database is nice, though it has performance implications in some areas. Especially with large(r) tables.
No, it's been there all the time. :) We ship an SDK with the complete object model documented. You as a customer can still download it and for example use our Template Studio (ala codesmith studio) to write little templates against it, and if you look into the object model, you'll see that you can load a project into memory in 1 line of code, and then every element is there, usable as a normal object graph, not through XML voodoo. :)
Nevertheless, you confuse mapping information needed to make mappings possible at design time and mapping information needed to make mappings possible at runtime. LLBLGen Pro uses code generation (which in fact 'pre-calculate' mapping interpretation for you in code) instead of a mapping file, which allows objects to travel freely through your application, distributed or not, without the necessity of a mapping file at every spot it is used.
You really don't know the amount of information available/required in the project file ;) If it was easy to pack all that info in a tiny little xml file, even in large projects, no problem. Though its not. Schema information of databases alone is very verbose.
Yeah, well, what you're refer to is the mapping file which is used at runtime. LLBLGen Pro doesn't use a slow XML file at runtime, but code generation at design time. And, do these tools have a gui designer which allow you to keep your schemas of multiple catalogs in your project file so you can work on it disconnected from your db? No, or when they do, you will be very surprised how big the data is when you serialize a full schema to XML. No-one with a right mind would do that, OR it would be a tool targeted towards small(er) applications. In enterprise development, having to deal with 10-20MB xml files is not what you want, I can tell you that. So, stripping out the info to allow you to make mappings in a designer, leaves smaller xml files, but then again, you don't have the info to make proper mappings in a designer, or better: let the designer do the work for you. Or are you suggesting that making mappings for 300 entities in an xml file BY HAND isbeing 'productive' ?
I count 1 feature which you could work around and a bad way to schedule your own work. Where are the 'major' flaws? I already admitted that it wasn't a great decision to return a new entity, but what can I do after that? Not much, just add a switch, after all, this is professional software, and that shouldn't break your applications when you apply a patch.
If you have noticed other 'major' flaws which were there in 2003, early 2004, tell me, though be aware that the version you've used is revisited a couple of times already, for example a complete different paradigm has been added.
Yes, of course I cleaned up the issues, I always do :). But some issues are design flaws as in 'it would have been better if...' and can only be countered by adding logic to switch off those features etc. as with a lot of customers with large projects, you can't just change something so fundamental as the issue with the returned entity on a lazy loading event, as that would break their applications.
I'm sorry your experience was not as you'd expected. I hope you understand that my options in the particular situation you're talking about weren't great (rock, hard place). Also I hope you'll understand that the difficulties you had with development in a distributed environment takes proper pre-cautions to make things run smoothly. You can't solve that by using XML files, you can only solve that by proper scheduling of work, because otherwise you're STILL fixing the results of inproper scheduled work, by hand, which can /will be cumbersome, time consuming AND above all.... error prone.
It's up to you, you're still a licensee, you can still take a look at the current version :)
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
fregas
Member
406 Points
96 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 24, 2005 04:47 PM|LINK
1) Of course we could test for the null object. We eventually found a work around for the issue, by specifically checking areas where the returned object had the potential of being null. That's not the point. The point is that the product wasn't very "developer friendly" if you forgot to do this, as we are all likely to do at times. Debugging this, as I said before, was a nightmare. And as you pointed out, the product wasn't even being consistent with itself, much less the .NET framework. You did get an error if you attempted orders[3].ProductName when you only had 2 orders in the entity collection, but you DIDN'T get an error when you said Order.Customer.FirstName if there wasn't an error there. I understand your thought process about objects being merely containers for data, although I think some people would disagree. Some people think along the lines of: "1 record equals 1 object instance. Missing record equals null object reference." This has always been my position, and I don't think that line of thinking is uncommon, but it is certainly debatable. IdeaBlade also instantiates an object if you try to reference something where the data isn't there, but that object is not saveable or changeable and is marked as a "Null".
2) I DO think you should strive to be consistent with how the .NET framework works. It drives me CRAZY when i get a UI product for example, that has a "disabled" or "Invisible" property rather than the traditional "enable" and "visible" properties that every other intrinsic web control has.
3) One can argue that our development process was the problem until you are blue in the face. To some extent, I agree. I prefer to either have everyone work off the same database and/or have only one person who is allowed to make database changes. I prefer to not allow multiple checkouts of files. However with the offsite developer, that wasn't always possible--and out of my control. It was an exception rather than the rule. Most of the time, we would not allow this parallel develpment. When it did happen, at least with the database, we could script our changes and synch up our changes by running them. With LLBLGen project files, we ran into a lot of trouble if we were both working on the project file at the same time. Also, keep in mind that many source control packages (other than VSS) allow parallel development and simulataneous checkout of files, and then have the developer perform a "diff". Many shops use this paradigm, and allow multiple developers to work in parallel. Most of the mapping solutions like WORM or NHibernate have pretty simple xml, because they don't do all that code generation for you so the mapping is easier to synch up. That's probably comparing apples to oranges since your product does the "mapping' and ALSO generates the code, therefore you have to store a lot more metadata. However, IdeaBlade does the same thing that LLBLGen does, and its XML file is very easy to edit, should 2 developers get out of synch. There IS a lot of XML if you lots of tables and fields, but its not complex. For the record, I don't consider XML "voodoo": its easy to read, easy to parse and doesn't require me to compile anything to make a change. I can open IdeaBlade's xml, make a change, open up the UI and see my changes in the UI. Your SDK does sound interesting though, and I'll have to take a look at it when I get some time.
5) We did have some other major problems with LLBLGen including some stuff that required hot fixes that you provided to us. This was fine, but the hot fixes either did not work or caused our project files between myself and the offsite developer to become incompatible, even though we used the same hot fixes. It wasn't really just the one issue with nulls, although obviosly that was the one that sticks out in my mind the most. Do you really want to address the rest of our issues here?
FransBouma
Participant
1509 Points
312 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 24, 2005 09:56 PM|LINK
Where did I point that out? It IS consistent with itself, I just added some things I found logical. Why should I stick to the .NET framework 'consistency' if the .NET framework isn't consistent either?
Of course things are debatable, and I agree with you that returning 'null' would have been better, as I've said a dozen times already. I also explained why that wasn't an option, and I hope that's all clear now. You also forget to mention you talk about a version which is more than a year old (before feb 2004)
True, but if I think something is more workable I use that. This null issue was a mistake from my part, but every products has mistakes in its design.
You really think you can do a diff on a large XML file which contains all the mapping info for a 300 entity project and work with that? Dream on :). Sure, that diff is made, but then you have to merge it by hand, which is tedious and error prone.
I don't know IdeaBlade, but I doubt they use the same amount of data to work with. LLBLGen Pro doesn't compromise on anything nor does it 'limit' you on database options like 'always use 1 field pk's' or other sillyness. That takes information and that eats up size. I did look into this a couple of times but it was impossible to make it useful. Take note that binary serialized data of a large project already takes some time to load, let along XML data of that magnitude... It's not fast enough.
No, I meant the code to get everything out of the XML dom document :).
No, that doesn't seem very useful for this forum. What I can't believe is that you now come to me that fixes for issues 'didn't work'. It's the first time I hear this kind of info, and IMHO if something which is supposed to be fixed isn't fixed for you, come to me and I'll check it out. Also the issue with your off-shore developer. You're not alone in that situation, so perhaps you could have learned from fellow llblgen pro users how to solve this, or I could have adviced you sooner.
Again, I'm sorry your experience isn't as nice as you'd expected, though much has changed since you've used it. But if you think XML files are the way to go, go ahead, I think you'll learn they have major drawbacks too. :)
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
serenay
Member
45 Points
9 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 27, 2005 01:45 PM|LINK
If you are interested to evaluate it, you can visit http://workspaces.gotdotnet.com/paladin and give me some comments.
I'm working on it as my hobby and I hope you guys can pardon the limitations as it is still a one woman's job for now.
fregas
Member
406 Points
96 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 27, 2005 10:36 PM|LINK
You mentioned this inconsistency earlier -- how in this ONE particular situation, you were doing something different than how you normally do it in LLBLGen:
However, in most other respects, your API is pretty consistent.
Actually, I find the .NET framework very consistent, especially compared to other languages such as VB6 and even Java. Consistency is really important, as it lessens the learning curve in any API and improves developer productivity.
Sorry, I thought we were still discussing my particular experience with you and your product, on that particular version. I was merely responding to your posts about what we could do or not do at that particular time. You seemed frustrated that we just didn't just obsessively check for "empty" objects all over the place (both back when I had originally emailed you about the issue, and now on the forums.) I was also explaining why I think it was a more serious issue than you gave credit to at the time.
In any case, I"m glad its since been fixed.
Nice sarcasm.
Of course I don't think something that big is going to be easy. But I was only trying to alter a FEW COLUMNS, on a relatively small schema, using your product. I think that SHOULD be easy. I think a 300 entity project would require a lot of work to synch up if two versions were out of wack, regardless of whether you're using XML or an object model.
On the other hand, I have done diffs on pretty large HTML/ASPX files, which isn't that much different from XML. As long as the thing generating the XML doens't change the order of the data each time (like VS.NET project files do) you shoudl be ok with a diff tool. Definitely not a walk in the park, but doable.
IdeaBlade definitely has its own quirks. I haven't noticed a performance hit when loading a project, but I haven't opened a really huge project yet. I'll have to defer to someone who's used the "XML based" mappers more than I have, as LLBLGen and CSLA (which is not a mapper) are the two products I've used the most. Has anyone had performance issues opening the IDE for IdeaBlade, Paul Wilson's WORM or NHibernate? I'm not sure the last one has an IDE, but I could be wrong.
Ah, well thats kind of your problem isn't it? I'm not saying outputting the project file would be easier for YOU, just easier for your customers to "eyeball." Kind of like we do with VS.NET solution and project files when something isn't easily fixable in the IDE. I can do a Find/Replace or Copy/Paste in a vs.net file pretty easily, because its xml, but I admit your files might be too big for that.
Also, I was thinking you would use the XML (Soap?) serialziation classes in .NET, which would load and save everything for you from the objects to disk as long as you marked those classes serializable. I wasn't thinking you would walk the document tree using the DOM. But it was just a suggestion. It may not be viable.
No we actually did ask for some hot fixes, downloaded them based upon your suggestion and could never get them quite right. Some of the issues we emailed you about, and some of it we did not. We ran out of time and just had to work around the issues. Also, you're outside the U.S. so I think the time difference made communcation more difficult. To be honest, we kind of gave up on you a bit when you didn't take the "NULL object" issue more seriously when I had emailed you about it. Your response was something along the lines of "read the documentation" and it didn't sound like you were ever going to fix it. So I gave up emailing you issues, because this kind of left a bad taste in my mouth. That was probably wrong of me, since you were only minimizing the importance of that one particular issue (which as you mentioned, has since been fixed), not telling me to not communicate with you at all.
There were some issues we simply did not report, because we couldn't wait for a response. I find this VERY, VERY common in software development. Users using your product will not report many bugs, simply because of the perceived time it would take to explain and wait for a solution, especially if they feel they've been talked down to. More commonly, they will work around the issues, or quit using the product, especially if those users happen to be developers.
Again, Frans I don't mean to make you defensive. I'm just telling you (and others) what my experience with the product and support was at that time. I think an O/R mapping product is a huge undertaking that I personally don't think I could manage alone. I give you credit for having solved a lot of the mapping problems very elegantly, even in that older version. I didn't start this thread to bash your product, but was telling people what I thought were major problems when I used it so they could give me possible alternatives.
FransBouma
Participant
1509 Points
312 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 28, 2005 09:50 AM|LINK
True. Although there's not a lot of difference between:
[code]CustomerEntity c = myOrder.Customer;
if(c.Fields.State!=EntityState.Fetched)
{
// doesn't exist
}
[/code]
and
[code]
CustomerEntity c = myOrder.Customer;
if(c==null)
{
// doesn't exist
}
[/code]
You always have to check, no matter what. If you don't check c if it's null, you'll run into other problems. That's why I didn't make it a big deal as well, checks were necessary. Though let's close this now, it's water under the bridge and we've said what we had to say about this[;)]
Could be, but I can't remember a day where we replied after 24 hours to a customer's support call. A time difference always is a problem, but not as big as you make it out to be. You mention here, again, that you never could get the hotfixes or upgrades right. I'm sorry, but if I download a fix for a 3rd party product I use and the fix doesn't work, I mail the vendor, till it works OK. I think that's normal.
I'm sorry if you felt been threated rudely, as that was nor is ever my intention. The thing is, if that happens again, just say so. Not communicating with a vendor about issues is of course not good.
You think? If I don't report a bug to a 3rd party vendor, I then also give up the right to complain about it. No offence but it was you who brought up not only an old issue in an old version but also did you say there were other major issues. I won't deny we had our share of major bugs in the product, as every software product has bugs and which get fixed and everyone moves on. The thing is that if you run into an issue, and you don't report it, for whatever reason, IMHO you then also give up the right to complain about them. Just report them, even if you can't wait for a fix.
But I then wonder: what was your intention in doing so? You post about a flaw in an old version, clearly about frustration and I understand that completely. Then later on mention 'major other issues' which are not always reported to us, plus you again say you couldn't work with the fixes we supplied. It's your right to vent about whatever you like of course, that's not why I write these postings here. What I want to achieve is that your bad customer experience is turned into a better customer experience, by explaining my reasons and also by giving hints how to improve future communication.
Because no matter which vendor's product you'll pick for your future project(s), if you don't communicate what's on your mind, it won't work out. [:)]
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
fregas
Member
406 Points
96 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 28, 2005 04:50 PM|LINK
I disagree. As I mentioned earlier, many, many bugs go unreported and the users just gripe to each other about the software, even when the software isn't made for other developers.
Its like going to a restaraunt: You order something, the food was mediocre and the service was bad. Now, that customer my or may not tell the owner or the waiter. They might throw a big scene, or they may be too shy, too non-confrontational or just too lazy to say anything. However, chances are they will tell their friends and aquaintences (and anyone else who will listen) not to eat there, and it is their right to do so.
It is up to the owner to be proactive and actually GO LOOKING for unhappy customers, figure out what their problems are and resolve them, before they leave the restaraunt. Its even more so in the software industry.
Initially, I mentioned these old flaws simply to avoid any other products that had similar flaws. My assumption is that these are issues that all ORM products have to contend with, certainly not just yours.
nite
Member
10 Points
2 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 29, 2005 05:32 PM|LINK
Also, does anyone know how to do client-side sorting of lists with Wilson ORM? Seems to be eluding me ...
Cheers,
Andy
rsmoke21
Contributor
3931 Points
792 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 29, 2005 06:03 PM|LINK
The way I usually view it (for better or worse) is:
- An object describes a concept (usually a real world concept) and contains both the data AND behaviors associated with the object. This allows consumers of the object to only worry about the object's interface (public methods) and not the object's underlying data structure or how it is implemented.
- An entity represents the data used to describe a concept, but NOT the behavior of the concept. The behaviors of the concept are contained in other classes that are outside the scope of the entity.
This may seem like a small semantic difference but it is an important point that ultimately can lead to very differen designs and implementations. I fall into the "object" category probably because that is the way I learned OO and software programming in general. I would say many people who prefer the "entity" approach have learned software from a more structured (or functional) point of view than an OO point of view. There's no absolute way which is best, but I do believe there are some powerful advantages to the OO view of encapsulation and abstraction.
Also, does anyone know how to do client-side sorting of lists with Wilson ORM? Seems to be eluding me ...
I don't know the Wilson O/R Mapper and have never used it. However, the ORM is not a GUI tool to the best of my knowledge. Anything client side is usually involved with the GUI and requires some sort of scripting language (javascript, vbscript, dhtml, etc). I would think that any client side sorting needs to be done by the control that you are using to display the lists rather than the list objects themselves...
mkamoski
Contributor
5694 Points
1565 Posts
Re: WORM, NHibernate and reviews of any other ORMappers
Jul 29, 2005 06:15 PM|LINK
nite--
I do not know how to do it on the client-side.
However on the server-side, as you probably have noticed, if one uses object-query language then one can sort at-will.
Alternately, it is possible to use the good old GetDataSet strategy, convert to a DataView, and then use the DataView to sort. This is not a bad solution (IMHO) for read-only views of the data.
HTH.
Thank you.
--Mark Kamoski